2008/9/2 Tom Lane <email@example.com>:
"Pavel Stehule" <firstname.lastname@example.org> writes:
2008/9/1 Tom Lane <email@example.com>:
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
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. +1
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).
It's well thought, but I afraid so this can hide some bug, and it's
little bit dangerous.
I thing, so we can simply duplicate values in result then allowing
duplicate params in function.
postgres=# create function foo(out a int, out b int) returns record as
$$ select 1,2 $$ language sql;
postgres=# select a, a, b from foo();
a | a | b
1 | 1 | 2
Duplicate arguments are more like copy-paste bug then good style. We
check it in column definition too:
postgres=# create function foo1() returns record as $$ select 1,1,2 $$
postgres=# select * from foo1() as (c int,c int,c int);
ERROR: column name "c" specified more than once
regards, tom lane