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?)
|
Список | 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 по дате отправления: