On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@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... > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers