Re: final patch - plpgsql: for-in-array - Mailing list pgsql-hackers

From Tom Lane
Subject Re: final patch - plpgsql: for-in-array
Date
Msg-id 3464.1290101784@sss.pgh.pa.us
Whole thread Raw
In response to Re: final patch - plpgsql: for-in-array  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: final patch - plpgsql: for-in-array
Re: final patch - plpgsql: for-in-array
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: EXPLAIN and nfiltered
Next
From: Pavel Stehule
Date:
Subject: Re: final patch - plpgsql: for-in-array