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