2009/3/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
