contrib/dblink regression test failure fix

Joe Conway <mail@joeconway.com> writes:

Attached is a patch to fix the current regression test failure for
contrib/dblink. The failure was induced by recent changes to cast
behavior.

Actually, I was going to suggest modifying the declaration of the
dblink function(s) to take integer instead of int2. Is there a
really good reason why they take int2? If not, there's little point
in putting up with a notational headache throughout the 7.3 cycle.

The problem should go away again in 7.4, when we tweak the parser to
initially type "2" as "2::int2" ... but for now the path of least
resistance would seem to be avoiding declaring functions to take int2.

regards, tom lane

Tom Lane wrote:

Actually, I was going to suggest modifying the declaration of the
dblink function(s) to take integer instead of int2. Is there a
really good reason why they take int2? If not, there's little point
in putting up with a notational headache throughout the 7.3 cycle.

The problem should go away again in 7.4, when we tweak the parser to
initially type "2" as "2::int2" ... but for now the path of least
resistance would seem to be avoiding declaring functions to take int2.

Good point. I only used int2 to be consistent with pg_class.relnatts.

Here is a revised patch. This uses an int4 input with a bit of checking to be
sure the given value fits in an int2 variable. This seemed the easiest and
safest approach. Please apply if there are no objections.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:

Here is a revised patch. This uses an int4 input with a bit of checking to be
sure the given value fits in an int2 variable. This seemed the easiest and
safest approach. Please apply if there are no objections.

Okay, patch applied --- I figured we'd better fast-track this into
beta2, since otherwise people might have a problem upgrading later.

regards, tom lane