2010/11/18 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2010/11/18 Tom Lane <tgl@sss.pgh.pa.us>:
>>> The problem here is that FOR is a syntactic choke point: it's already
>>> overloaded with several different sub-syntaxes that are quite difficult
>>> to separate. Adding another one makes that worse, with the consequences
>>> that we might misinterpret the user's intent, leading either to
>>> misleading/unhelpful error messages or unexpected runtime behavior.
>
>> yes, this argument is correct - but we can rearange a parser rules
>> related to FOR statement. It can be solved.
>
> No, it can't. The more things that can possibly follow FOR, the less
> likely that you correctly guess which one the user had in mind when
> faced with something that's not quite syntactically correct. Or maybe
> it *is* syntactically correct, only not according to the variant that
> the user thought he was invoking. We've seen bug reports of this sort
> connected with FOR already; in fact I'm pretty sure you've responded to
> a few yourself. Adding more variants *will* make it worse. We need
> a decent return on investment for anything we add here, and this
> proposal just doesn't offer enough benefit.
>
yes I reported a allowing a labels on "wrong" position. But minimally
this patch must not to change a current behave. It's your idea to use
keyword "ARRAY" there. Maybe we have just only different view on
complexity. My proposal increase complexity in parser, your proposal
in executor. Anybody thinking so other variant is worst. I don't speak
so we have to have a just FOR IN ARRAY syntax - I though so there was
a agreement on last discus. We can use a different syntax - but should
be readable.
Regards
Pavel Stehule
> regards, tom lane
>