"Brendan Jurd" <dire...@gmail.com> writes:
> So if I had these two functions ...
> var1(a int, b variadic int[])
> var2(a int, b variadic anyarray)
> ... it would be okay to write var1(8), which resolves as var1(8,
> array[]::int[]). But if I tried to write var2(8) I'd get an error.
> Maybe something like "cannot determine type of missing variadic
> arguments".
Well, we could unify these behaviors if we insisted on an explicit
default to omit the argument in both cases.
var1(a int, b variadic int[] default '{}'::int[])
var2(a int, b variadic anyarray default '{}'::text[]) -- perhaps
In both cases, supplying a single argument would be legal if and only
if you provided a default for the variadic parameter. As soon as you
give two arguments, the default isn't relevant anymore. This method
eliminates the discrepancy between anyarray and other types of variadic
parameters, and it leaves the door open for someone to use something
besides an empty array as the default. (Who are we to say that such a
thing is never useful? NULL seems like a possibly useful default for
instance.) I think it also makes the variadic and default features
a bit more orthogonal.
This still leaves us with the annoyance of having to prevent changes in
the actual datatype of a default associated with a polymorphic parameter;
but that's just some implementation tedium, and I'm beginning to find
it more attractive than the alternatives.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
