Re: final patch - plpgsql: for-in-array

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: final patch - plpgsql: for-in-array
Дата
Msg-id 3464.1290101784@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: final patch - plpgsql: for-in-array  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: final patch - plpgsql: for-in-array  (Robert Haas <robertmhaas@gmail.com>)
Re: final patch - plpgsql: for-in-array  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Syntactic sugar is not entirely to be despised, anyway.

If it were harmless syntactic sugar I wouldn't be objecting so loudly.
The problem here is that FOR is a syntactic choke point: it's already
overloaded with several different sub-syntaxes that are quite difficult
to separate.  Adding another one makes that worse, with the consequences
that we might misinterpret the user's intent, leading either to
misleading/unhelpful error messages or unexpected runtime behavior.
If you consult the archives you can find numerous past instances of
complaints from people who hit such problems with the existing set of
FOR sub-syntaxes, so this isn't hypothetical.

I'm also quite afraid of having a conflict with other future extensions
of FOR, which we might want to introduce either on our own hook or for
compatibility with something Oracle might add to PL/SQL in future.

This might not be the worst place in the entire system to be introducing
inessential syntactic sugar, but it's certainly one of the top ten.
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: EXPLAIN and nfiltered
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: final patch - plpgsql: for-in-array