Is this really really as designed or defined in some standard

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

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

> 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

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
>

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

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
>

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

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

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
>

"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

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
>

"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

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