Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Дата
Msg-id AANLkTimBbvVB32+eGsx0HAtfK=11A+++fycM7EkFS_xJ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Unfortunately, there are likely to be a limited number of such
>> keywords available.  While I agree it's helpful to have a clear
>> distinction between what FOR does and what FOREACH does, it's wholly
>> conventional here and won't be obvious without careful reading of the
>> documentation.  If we had FOR and FOREACH and FOREVERY and, uh,
>> FORGET, it'd quickly become notational soup.
>
> All true, but in the absence of any plausible candidate for third or
> fourth or fifth types of iteration, this objection seems a bit thin.

Well, Heikki just pointed out one that Oracle supports, so that makes
at least #3...

>> I am still wondering if
>> there's a way to make something like "FOR ELEMENT e IN a" work.  I
>> suspect we'd be less likely to paint ourselves into a corner that way.
>
> I'm afraid that's only really feasible if you are willing for the second
> word to be a fully reserved word, so it can be distinguished from a
> plain variable name in that position.

What if we cheat and peak ahead an extra token?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: ps_status on fastpath
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: unlogged tables vs. GIST