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

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
>

In response to

Responses

Browse pgsql-hackers by date

  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