Re: final patch - plpgsql: for-in-array

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: final patch - plpgsql: for-in-array
Date: 2010-11-18 19:16:34
Message-ID: 5570.1290107794@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2010/11/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-11-18 19:17:40 Re: final patch - plpgsql: for-in-array
Previous Message Alvaro Herrera 2010-11-18 19:16:10 Re: describe objects, as in pg_depend