| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?) |
| Date: | 2010-12-17 19:08:15 |
| Message-ID: | 4D0BB51F.5010903@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 17.12.2010 21:04, Robert Haas wrote:
> 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. 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.
As a side note, Oracle has FORALL, which is a kind of bulk update
operation over a collection type. So whatever we choose, not FORALL...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2010-12-17 19:13:25 | Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?) |
| Previous Message | Tom Lane | 2010-12-17 19:07:22 | Re: unlogged tables vs. GIST |