Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers