2008/9/2 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/9/1 Tom Lane <tgl@sss.pgh.pa.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.
>
+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
>
