Re: functional call named notation clashes with SQL feature

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: functional call named notation clashes with SQL feature
Дата
Msg-id AANLkTil4g5bX6t_yz5H4TZOk25mE-GORHtVnbZeoQkT5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: functional call named notation clashes with SQL feature  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
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
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature