"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/7/13 Jeff Davis <pgsql@j-davis.com>:
>> 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 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.
As far as the "variadic int" versus "variadic int[]" business, I'm
starting to agree with Pavel that "variadic int[]" offers less potential
for confusion. In particular, it seems to make it more obvious for the
function author that the argument he receives is an array. Also, the
other one would mean that what we put into pg_proc.proargtypes doesn't
agree directly with what the user thinks the argument types are. While
I think we could force that to work, it's not exactly satisfying the
principle of least surprise.
One issue that just occurred to me: what if a variadic function wants to
turn around and call another variadic function, passing the same array
argument on to the second one? This is closely akin to the problem
faced by C "..." functions, and the solutions are pretty ugly (sprintf
vs vsprintf for instance). Can we do any better? At least in the
polymorphic case, I'm not sure we can :-(.
regards, tom lane
