Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David E. Wheeler" <david@kineticode.com>, Andrew Dunstan <andrew@dunslane.net>, Pavel Stehule <pavel.stehule@gmail.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Merlin Moncure <mmoncure@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-12-17T19:43:21Z
Lists: 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