Re: WIP: named and mixed notation support

2009/3/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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)