From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Proposal: plpgsql - "for in array" statement |
Date: | 2010-09-29 02:32:17 |
Message-ID: | 4CA2A531.7030904@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/28/2010 09:43 PM, Darren Duncan wrote:
> Alvaro Herrera wrote:
>> What about
>>
>> FOR EACH var IN array_expr LOOP ...
>>
>> I think this requires reserving EACH, which could cause a regression for
>> working code. Maybe there's a way to make it work?
>
> What about saying FOR-EACH instead?
>
> A good general solution that I'd expect to not cause regressions is to
> separate multiple-word keywords with dashes rather than spaces.
>
> Since unquoted identifiers don't have dashes, I think, and moreover
> because the whole FOR-EACH would occupy the first position of the
> statement rather than the first two, there should be no ambiguity.
>
> Parsing should be easier, too, because keywords formatted like this
> would just be a single term rather than having infinite variations due
> to embedded whitespace.
This would actually make the parsing infinitely more ugly, not less. And
we are not gong to start introducing non-alphabetic characters into
keywords. It is also, as Tom noted about the earlier version, without
any obvious connection to array processing.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-29 02:47:08 | is sync rep stalled? |
Previous Message | Andrew Dunstan | 2010-09-29 02:27:08 | Re: Proposal: plpgsql - "for in array" statement |