On Sun, 2008-07-13 at 12:32 -0400, Tom Lane wrote:
> >> Also, it doesn't seem to allow calls to a variadic function with zero
> >> arguments, e.g. "mleast()". I think this should be allowed.
>
> > It's not possible for all cases, because empty array have be typed
> > array still. But for non polymorphic variadic functions it's probably
> > possible - I would to solve this question later - and for now use
> > overloading etc
>
> I don't really like the idea of a feature that would work except in the
> polymorphic case --- that just seems too non-orthogonal. Also I tend
> to think that a pretty large fraction of variadic functions will be
> polymorphic, making the feature's usefulness even more dubious.
I think it has the potential for surprise both ways. I was surprised
when it didn't allow a zero-argument call.
> I concur with the idea that variadic functions should only match to
> calls that offer at least one value for the variadic array. If you can
> actually define the behavior sensibly for the zero-element case, a
> separate function of the same name can cover that case.
Similarly, if zero-argument calls to variadic functions were allowed,
and you want the polymorphism to work as you suggest, you can just
define:
foo(int, variadic int[])
foo(text, variadic text[])
and that forces one argument to be provided, and the functions don't
conflict. If this is the common case, I can see why you wouldn't want to
require declaration of the extra parameter each time.
I don't have a strong opinion, but allowing zero-argument variadic
function calls -- and therefore causing foo(variadic int[]) and
foo(variadic text[]) to conflict -- makes more sense than requiring one
argument. It also seems a little more natural from a function author's
perspective.
Regards,
Jeff Davis
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
