Re: functional call named notation clashes with SQL feature

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: functional call named notation clashes with SQL feature
Дата
Msg-id 5084.1274919671@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: functional call named notation clashes with SQL feature  (alvherre <alvherre@commandprompt.com>)
Ответы Re: functional call named notation clashes with SQL feature  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
alvherre <alvherre@commandprompt.com> writes:
> 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.

"Sucks" is not the word; "utterly unacceptable" is the word.  Having an
expression mean different things depending on context is a recipe for
unbelievable nightmares.  Can you imagine dealing with that in a query
generator for example?  Or even ruleutils.c?

If we go with the spec's syntax I think we'd have no realistic choice
except to forbid => altogether as an operator name.  (And no, I'm not
for that.)
        regards, tom lane


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Distclean does not remove gram.c
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT