Re: functional call named notation clashes with SQL feature

2010/6/5 Greg Stark <gsstark@mit.edu>:
> On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, that really isn't going to work: how will the parser know that the
>> names are not meant to match to actual named parameters of the function?
>> You could possibly do it with a special case for hstore() in the
>> grammar, but we aren't going there, because it wouldn't be extensible.
>>
>
> I wonder if we could offer something like VARIADIC but allows
> arbitrarily named parameters which get passed in a hstore-like hash
> instead of an array. Just thinking aloud here. I haven't thought about
> what this would mean in the function call api.
>

I like this idea. Using a named expression for variadic parameter can
be way. Maybe have to be explicitly enabled. Then we don't need
special keyword or special syntax.

like

CREATE OR REPLACE FUNCTION hstore_constructor(VARIADIC params "anyelement"[])
AS $$ ... $$ STORE_PARAM_NAMES

and maybe we can emulate old behave of hstore.

Regards
Pavel Stehule


> --
> greg
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>