Re: variadic function support

2008/7/14 Florian G. Pflug <[email protected]>:
> Pavel Stehule wrote:
>>>
>>> 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 :-(.
>>>  maybe with some flag like PARAMS?
>>
>> SELECT least(PARAMS ARRAY[1,2,3,4,5,6])
>
> Just FYI, this is more or less how ruby handles variadic functions - a
> "*" before the last argument in the function's *definition* causes all
> additional arguments to be stored in an array, while a "*" before the
> last argument in a function *call* expands an array into single arguments.
>
> So, you could e.g do
> def variadic1(a, b, *c)
>  # c is in array containing all parameters after second one.
> end
>
> def variadic_wrapper(a, *b)
>  variadic1("foobar", a, *b)
> end
>
> So there is precedent for the "flag idea" too. Plus, I kind of like the
> idea of using the same syntax for both wrapping and unwrapping of variadic
> arguments.
>
> regards, Florian Pflug
>

ok - it's possible, I''l look in this direction - and it's should be
usable in plpgsql - we should be able call variadic functions from
plpgsql with immutable number of arguments without dynamic SQL.

sample: select mleast(variadic array[1,2,3,4,5]);

so I wouldn't do ruby from plpgsql :). Still my goal is well support
for libraries like JSON or XML.

select json_object(name as 'name', prop as 'prop') --> '[name: xxxx,
prop: yyyy ...

It's not strong like  SQL/XML, but it is independent on parser, and
could exists outside. So my next step is named parameters in SELECT
statement.

Regards
Pavel Stehule
>

-- 
Sent via pgsql-patches mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches