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

Is this really really as designed or defined in some standard

From
Hannu Krosing
Date:
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




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

From
David Fetter
Date:
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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


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

From
Dennis Bj\xF6rklund
Date:
> 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



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

From
"Pavel Stehule"
Date:
Hello

2008/8/31 Hannu Krosing <hannu@2ndquadrant.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


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

From
Magnus Hagander
Date:
Pavel Stehule wrote:
> Hello
> 
> 2008/8/31 Hannu Krosing <hannu@2ndquadrant.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


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

From
"Pavel Stehule"
Date:
2008/9/1 Magnus Hagander <magnus@hagander.net>:
> Pavel Stehule wrote:
>> Hello
>>
>> 2008/8/31 Hannu Krosing <hannu@2ndquadrant.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
>


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

From
Hannu Krosing
Date:
On Mon, 2008-09-01 at 11:15 +0200, Pavel Stehule wrote:
> 2008/9/1 Magnus Hagander <magnus@hagander.net>:
> > Pavel Stehule wrote:
> >> Hello
> >>
> >> 2008/8/31 Hannu Krosing <hannu@2ndquadrant.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




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

From
Tom Lane
Date:
Hannu Krosing <hannu@2ndQuadrant.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


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

From
"Pavel Stehule"
Date:
2008/9/1 Tom Lane <tgl@sss.pgh.pa.us>:
> Hannu Krosing <hannu@2ndQuadrant.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
>


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

From
Tom Lane
Date:
"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.

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


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

From
"Pavel Stehule"
Date:
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
>


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

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


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

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