Re: variadic function support

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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches