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
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
Sent via pgsql-patches mailing list (email@example.com)
To make changes to your subscription: