Re: variadic function support - Mailing list pgsql-patches

From Pavel Stehule
Subject Re: variadic function support
Date
Msg-id 162867790807140617s105a0a5ew61100897db52d23b@mail.gmail.com
Whole thread Raw
In response to Re: variadic function support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
2008/7/13 Tom Lane <tgl@sss.pgh.pa.us>:
> "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 :-(.
>

fixed version
Thanks for comments

Pavel

Attachment

pgsql-patches by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: variadic function support
Next
From: "Florian G. Pflug"
Date:
Subject: Re: variadic function support