|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: final patch - plpgsql: for-in-array|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Syntactic sugar is not entirely to be despised, anyway.
If it were harmless syntactic sugar I wouldn't be objecting so loudly.
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.
If you consult the archives you can find numerous past instances of
complaints from people who hit such problems with the existing set of
FOR sub-syntaxes, so this isn't hypothetical.
I'm also quite afraid of having a conflict with other future extensions
of FOR, which we might want to introduce either on our own hook or for
compatibility with something Oracle might add to PL/SQL in future.
This might not be the worst place in the entire system to be introducing
inessential syntactic sugar, but it's certainly one of the top ten.
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
regards, tom lane
|Next Message||Pavel Stehule||2010-11-18 17:43:29||Re: final patch - plpgsql: for-in-array|
|Previous Message||Robert Haas||2010-11-18 17:26:33||Re: EXPLAIN and nfiltered|