From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is this really really as designed or defined in some standard |
Date: | 2008-09-02 07:16:24 |
Message-ID: | 162867790809020016u4b959429id15bd8006ec7f93c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2008/9/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "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.
>
+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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen R. van den Berg | 2008-09-02 08:07:52 | COPY statement cannot take binding parameters |
Previous Message | Tom Lane | 2008-09-02 07:14:07 | Re: Window functions patch v04 for the September commit fest |