Thread: WIP: named and mixed notation support

Hello

Attachment contains patch for support mixed and named notation with
special (PostgreSQL) syntax as was talked before.

postgres=# create function dfunc(a int, b int = 1, c int) returns
table (a int, b int, c int) as $$
  select $1, $2, $3;
$$ language sql;
CREATE FUNCTION
postgres=# select * from dfunc(10,20,30);
 a  | b  | c
----+----+----
 10 | 20 | 30
(1 row)

postgres=# select * from dfunc(10 as a, 30 as c);
 a  | b | c
----+---+----
 10 | 1 | 30
(1 row)

postgres=# select * from dfunc(30 as c, 10 as a);
 a  | b | c
----+---+----
 10 | 1 | 30
(1 row)

postgres=# select * from dfunc(10, 30 as c);
 a  | b | c
----+---+----
 10 | 1 | 30
(1 row)

postgres=#

this patch is bigger, because I had to add column to pg_proc - colum
contains map of defaults arguments:

postgres=# select * from pg_proc where proname='dfunc';
-[ RECORD 1
]----+-------------------------------------------------------------------------------------------------------------------------------------
proname          | dfunc
pronamespace     | 2200
proowner         | 16384
prolang          | 14
procost          | 100
prorows          | 1000
provariadic      | 0
proisagg         | f
proiswindow      | f
prosecdef        | f
proisstrict      | f
proretset        | t
provolatile      | v
pronargs         | 3
pronpargdefaults | 0
prorettype       | 2249
proargtypes      | 23 23 23
proallargtypes   | {23,23,23,23,23,23}
proargmodes      | {i,i,i,t,t,t}
proargnames      | {a,b,c,a,b,c}
proargdefaults   | (<> {CONST :consttype 23 :consttypmod -1 :constlen
4 :constbyval true :constisnull false :location 37 :constvalue 4 [ 1 0
0 0 ]} <>)
proargdefmap     | {n,d,n}
prosrc           |
                 :   select $1, $2, $3;
                 :
probin           |
proconfig        |
proacl           |

regards
Pavel Stehule

Pavel Stehule <pavel.stehule@gmail.com> writes:
> postgres=# create function dfunc(a int, b int = 1, c int) returns
> table (a int, b int, c int) as $$
>   select $1, $2, $3;
> $$ language sql;

The above is simply a horrid idea.  It'll completely break any ability
to resolve ambiguous function calls in a sane way.  What, for example,
will you do given "dfunc(1,2)" and alternatives

create function dfunc(a int, b int = 1, c int) ...
create function dfunc(a int, b int, c int = 1) ...

We should *not* remove the restriction that all parameters after the
first one with a default also have to have defaults.
        regards, tom lane

2009/3/2 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> postgres=# create function dfunc(a int, b int = 1, c int) returns
>> table (a int, b int, c int) as $$
>>   select $1, $2, $3;
>> $$ language sql;
>
> The above is simply a horrid idea.  It'll completely break any ability
> to resolve ambiguous function calls in a sane way.  What, for example,
> will you do given "dfunc(1,2)" and alternatives

no, it's not ambigonous, because named (mixed) notation and positional
notation is distinct.

>
> create function dfunc(a int, b int = 1, c int) ... - var A
> create function dfunc(a int, b int, c int = 1) ... - var B
>

yes, this case should be prohibited. what will be executed for
dfunc(10,20,30) - A or B?

Regards
Pavel

> We should *not* remove the restriction that all parameters after the
> first one with a default also have to have defaults.
>

I don't thing it. Function like fx(some with defaults, some) should be
called only in named notation or with full set of parameters. For
position notation (current behave) this function is invisible.So your
restriction is maybe not necessary, but restriction should be good for
simplicity - then I don't need default bitmap and it's true, so it's
enough for probably an most used case

func([non optional params], named optional flags with default)