Re: functional call named notation clashes with SQL feature

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: functional call named notation clashes with SQL feature
Дата
Msg-id 4BFDB129.1050107@enterprisedb.com
обсуждение исходный текст
Ответ на Re: functional call named notation clashes with SQL feature  (alvherre <alvherre@commandprompt.com>)
Ответы Re: functional call named notation clashes with SQL feature  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On 27/05/10 02:09, alvherre wrote:
> Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
>
>> I think we should fix it now.  Quick thought: maybe we could use FOR
>> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
>> mechanism for this is 'paramname =>  value', but I think that has
>> problems because of our possibly use of =>  as an operator - otherwise
>> that would be by far the best way to go.
>
> I think we were refraining from =>  because the standard didn't specify
> this back then -- AFAIU this was introduced very recently.  But now that
> it does, and that the syntax we're implementing conflicts with a
> different feature, it seems wise to use the standard-mandated syntax.
>
> The problem with the =>  operator seems best resolved as not accepting
> such an operator in a function parameter, which sucks but we don't seem
> to have a choice.  Perhaps we could allow "=>" to resolve as the
> operator for the case the user really needs to use it; or a
> schema-qualified operator.

AFAIU, the standard doesn't say anything about named parameters. Oracle 
uses =>, but as you said, that's ambiguous with the => operator.

+1 for FOR.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: CIText and pattern_ops
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Exposing the Xact commit order to the user