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'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. In particular, there's too much
knowledge at the lexer level instead of the grammar --- you'd have to
have a way of keeping the lexer from returning T_DATUM in this one
particular context, even if "element" happened to match some variable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
