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

On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)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...
>
> If you posit that we might someday wish to support what Oracle is doing
> there, it seems to me to be a precedent for using a different first
> keyword, not for what you're suggesting.  I'm not arguing that we might
> want to duplicate Oracle's syntax; only that if it's going to be cited
> as a precedent that we consider what it's actually a precedent for.

I don't quite follow what you're getting at here. My goal was to try
to think of something more mnemonic than FOREACH, and I thought
something involving the word "element" or "array" would do the trick.
The problem is only to find a place to put it that's before the word
"IN". But maybe that's hopeless and we should just go with FOREACH.

>>> 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?
>
> plpgsql's parser is rickety enough that I don't have a lot of confidence
> in its ability to do things that way.

Bummer. Rickety is not good.

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