Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:
regression=# create function fv (f1 int, f2 variadic int[]) returns int
regression-# as 'select $1' language sql;
CREATE FUNCTION
regression=# select fv(1,2);fv
---- 1
(1 row)
regression=# select fv(1,2,3);fv
---- 1
(1 row)
regression=# select fv(1);
ERROR: function fv(integer) does not exist
LINE 1: select fv(1); ^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics, because a default would
conflict with this behavior (ie, there would be sort of a
system-supplied default of an empty array). On the other hand, if we
don't want to change this behavior, then I'd like to be able to specify
"array[]::int[]" as the variadic's default so that I can make the corner
case go away when I want to. Either way the current behavior seems
unsatisfactory.
A related point is that, because the current code forbids a default
for a variadic, you can't do something like
create function foo (f1 int, f2 int default = 42, f3 variadic int[] = array[]::int[])
ie there's no way to have defaults on the preceding parameters either.
I don't know how useful that is, but maybe it's an argument for adopting
the second solution where you can explicitly specify a default for a
variadic.
Comments?
regards, tom lane