Re: Is this really really as designed or defined in some standard

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/9/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> However, since this is a behavioral change that could break code that
>> works now, I think it should be a HEAD-only change; no backpatch.

> I agree - it's could break only 100% wrong code, but it could problems
> in minor update.

> Could you backpach only warning?

I'm not for that. I dislike back-patching changes that are not the same
as what goes into CVS HEAD, because that means those changes will go out
in minor releases of stable branches without any detectable amount of
developer testing.

If we thought this was a change that really deserved incremental
warnings, then the right thing would be to make it a warning in 8.4 and
an error in some later release. And maybe even make a GUC variable to
control that behavior. But I don't think it's worth that.

An error starting in 8.4 seems entirely sufficient from where I sit.

BTW, there are actually two separate issues here: input parameters and
output parameters. After brief thought it seems like we should enforce
uniqueness of non-omitted parameter names for IN parameters (including
INOUT), and separately enforce uniqueness of non-omitted parameter names
for OUT parameters (including INOUT).

regards, tom lane