2008/9/2 Tom Lane <[EMAIL PROTECTED]>: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> 2008/9/1 Tom Lane <[EMAIL PROTECTED]>: >>> 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. >
+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; CREATE FUNCTION postgres=# select a, a, b from foo(); a | a | b ---+---+--- 1 | 1 | 2 (1 row) 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 $$ language sql; CREATE FUNCTION postgres=# select * from foo1() as (c int,c int,c int); ERROR: column name "c" specified more than once Pavel > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
