Lists: | pgsql-hackers |
---|
From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Is this really really as designed or defined in some standard |
Date: | 2008-08-31 21:55:21 |
Message-ID: | 1220219721.17281.5.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
It seems that we allow several function arguments to have same
name (or is it label :)
hannu=# create or replace function ff(a int, a int) returns int language
plpgsql as $$begin return $1+$2; end;$$;
CREATE FUNCTION
hannu=# select ff(1,1);
ff
----
2
(1 row)
hannu=# select ff(1,2);
ff
----
3
(1 row)
hannu=# create or replace function ffa(a int, a int) returns int
language plpgsql as $$begin return a + a; end;$$;
CREATE FUNCTION
hannu=# select ffa(1,2);
ffa
-----
2
(1 row)
Is this defined by some standard or just an oversight ?
----------------------
Hannu
From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is this really really as designed or defined in some standard |
Date: | 2008-08-31 22:22:07 |
Message-ID: | 20080831222207.GH3717@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Mon, Sep 01, 2008 at 12:55:21AM +0300, Hannu Krosing wrote:
> It seems that we allow several function arguments to have same
> name (or is it label :)
Ugh!
> hannu=# create or replace function ff(a int, a int) returns int language
> plpgsql as $$begin return $1+$2; end;$$;
> CREATE FUNCTION
> hannu=# select ff(1,1);
> ff
> ----
> 2
> (1 row)
>
> hannu=# select ff(1,2);
> ff
> ----
> 3
> (1 row)
>
> hannu=# create or replace function ffa(a int, a int) returns int
> language plpgsql as $$begin return a + a; end;$$;
> CREATE FUNCTION
> hannu=# select ffa(1,2);
> ffa
> -----
> 2
> (1 row)
>
> Is this defined by some standard or just an oversight ?
This looks like a bug.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From: | Dennis Bjrklund <db(at)zigo(dot)dhs(dot)org> |
---|---|
To: | "Hannu Krosing" <hannu(at)2ndQuadrant(dot)com> |
Cc: | "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-01 06:25:29 |
Message-ID: | 992a93c9b2afeb9758d0a04ca27ba776.squirrel@zigo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
> hannu=# create or replace function ffa(a int, a int) returns int
> language plpgsql as $$begin return a + a; end;$$;
> CREATE FUNCTION
> hannu=# select ffa(1,2);
> ffa
> -----
> 2
> (1 row)
>
> Is this defined by some standard or just an oversight ?
It's just an oversight.
What about the similar program
create or replace function ffa(int, int)
returns int language plpgsql
as $$
DECLARE
a ALIAS FOR $1;
a ALIAS FOR $2;
begin
return a + a;
end;
$$;
I think ffa(a int, a int) should give an error but I don't know if the
ALIAS example above should (or even if it does, I don't have a pg
installation here to try it).
/Dennis
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com> |
Cc: | "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-01 07:35:14 |
Message-ID: | 162867790809010035m5dc27151ie270b35a3e9c751d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hello
2008/8/31 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
> It seems that we allow several function arguments to have same
> name (or is it label :)
>
> hannu=# create or replace function ff(a int, a int) returns int language
> plpgsql as $$begin return $1+$2; end;$$;
> CREATE FUNCTION
> hannu=# select ff(1,1);
> ff
> ----
> 2
> (1 row)
>
> hannu=# select ff(1,2);
> ff
> ----
> 3
> (1 row)
>
> hannu=# create or replace function ffa(a int, a int) returns int
> language plpgsql as $$begin return a + a; end;$$;
> CREATE FUNCTION
> hannu=# select ffa(1,2);
> ffa
> -----
> 2
> (1 row)
>
> Is this defined by some standard or just an oversight ?
>
what is problem? You have two diferent functions. I don't see anything wrong.
Pavel
> ----------------------
> Hannu
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Hannu Krosing <hannu(at)2ndquadrant(dot)com>, 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-01 07:53:06 |
Message-ID: | 48BB9F62.2060102@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Pavel Stehule wrote:
> Hello
>
> 2008/8/31 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
>> It seems that we allow several function arguments to have same
>> name (or is it label :)
>>
>> hannu=# create or replace function ff(a int, a int) returns int language
>> plpgsql as $$begin return $1+$2; end;$$;
>> CREATE FUNCTION
>> hannu=# select ff(1,1);
>> ff
>> ----
>> 2
>> (1 row)
>>
>> hannu=# select ff(1,2);
>> ff
>> ----
>> 3
>> (1 row)
>>
>> hannu=# create or replace function ffa(a int, a int) returns int
>> language plpgsql as $$begin return a + a; end;$$;
>> CREATE FUNCTION
>> hannu=# select ffa(1,2);
>> ffa
>> -----
>> 2
>> (1 row)
>>
>> Is this defined by some standard or just an oversight ?
>>
>
> what is problem? You have two diferent functions. I don't see anything wrong.
Take a look at the second function again. It's certainly not behaviour
that I would expect :-) (I would expect a syntax error)
//Magnus
From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Magnus Hagander" <magnus(at)hagander(dot)net> |
Cc: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>, "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-01 09:15:56 |
Message-ID: | 162867790809010215r5abd686bj6fc1ad7e6c0ae6b1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2008/9/1 Magnus Hagander <magnus(at)hagander(dot)net>:
> Pavel Stehule wrote:
>> Hello
>>
>> 2008/8/31 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
>>> It seems that we allow several function arguments to have same
>>> name (or is it label :)
>>>
>>> hannu=# create or replace function ff(a int, a int) returns int language
>>> plpgsql as $$begin return $1+$2; end;$$;
>>> CREATE FUNCTION
>>> hannu=# select ff(1,1);
>>> ff
>>> ----
>>> 2
>>> (1 row)
>>>
>>> hannu=# select ff(1,2);
>>> ff
>>> ----
>>> 3
>>> (1 row)
>>>
>>> hannu=# create or replace function ffa(a int, a int) returns int
>>> language plpgsql as $$begin return a + a; end;$$;
>>> CREATE FUNCTION
>>> hannu=# select ffa(1,2);
>>> ffa
>>> -----
>>> 2
>>> (1 row)
>>>
>>> Is this defined by some standard or just an oversight ?
>>>
>>
>> what is problem? You have two diferent functions. I don't see anything wrong.
>
> Take a look at the second function again. It's certainly not behaviour
> that I would expect :-) (I would expect a syntax error)
I see it now - it's really bug
Pavel
>
> //Magnus
>
From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | 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-01 13:08:23 |
Message-ID: | 1220274503.7124.5.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Mon, 2008-09-01 at 11:15 +0200, Pavel Stehule wrote:
> 2008/9/1 Magnus Hagander <magnus(at)hagander(dot)net>:
> > Pavel Stehule wrote:
> >> Hello
> >>
> >> 2008/8/31 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
> >>>
> >>> hannu=# create or replace function ffa(a int, a int) returns int
> >>> language plpgsql as $$begin return a + a; end;$$;
> >>> CREATE FUNCTION
> >>> hannu=# select ffa(1,2);
> >>> ffa
> >>> -----
> >>> 2
> >>> (1 row)
> >>>
> >>> Is this defined by some standard or just an oversight ?
> >>>
> >>
> >> what is problem? You have two diferent functions. I don't see anything wrong.
> >
> > Take a look at the second function again. It's certainly not behaviour
> > that I would expect :-) (I would expect a syntax error)
>
> I see it now - it's really bug
There are a few places, where repeating labels are allowed, for example
select can produce such record
hannu=# select 1 as a, 2 as a;
a | a
---+---
1 | 2
(1 row)
But it is not allowed in TYPE or table definitions
hannu=# create type aa as (a int, a int);
ERROR: column "a" specified more than once
hannu=# create table aa (a int, a int);
ERROR: column "a" specified more than once
It probably is also not allowed in function/procedure argument list, but
I was not sure that any standard would not require it.
So, should this be fixed at calling / SQL side (by not allowing
repeating argument names) or at pl side for each pl separately ?
--------------
Hannu
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(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-01 21:02:25 |
Message-ID: | 17970.1220302945@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> So, should this be fixed at calling / SQL side (by not allowing
> repeating argument names) or at pl side for each pl separately ?
I'm for fixing it just once, ie, in CREATE FUNCTION. I can't imagine
any scenario where it's a good idea to have duplicate function parameter
names.
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.
regards, tom lane
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 06:46:19 |
Message-ID: | 162867790809012346y2e346918vc19d83c9cb850106@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2008/9/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
>> So, should this be fixed at calling / SQL side (by not allowing
>> repeating argument names) or at pl side for each pl separately ?
>
> I'm for fixing it just once, ie, in CREATE FUNCTION. I can't imagine
> any scenario where it's a good idea to have duplicate function parameter
> names.
>
> 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?
regards
Pavel
>
> regards, tom lane
>
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
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:01:45 |
Message-ID: | 7182.1220338905@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"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.
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).
regards, tom lane
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 |
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: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
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 14:54:08 |
Message-ID: | 13824.1220367248@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/9/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 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.
Um ... what? I'm not sure what behavior you're proposing here.
regards, tom lane
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 15:02:24 |
Message-ID: | 162867790809020802m5f4c698ct7a281ea88b85d5ae@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> 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.
>
> Um ... what? I'm not sure what behavior you're proposing here.
>
> regards, tom lane
>
I am sorry - I really have to learn english. Simply I don't thing, so
duplicit OUT parameters is good idea, but I am haven't strong
objections - some programmer's bugs are visible in this case.
regards
Pavel