Re: final patch - plpgsql: for-in-array
От | Pavel Stehule |
---|---|
Тема | Re: final patch - plpgsql: for-in-array |
Дата | |
Msg-id | AANLkTin+2UwjvqOEifYFdD=NEANyS1fN2g4jYi43yedU@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: final patch - plpgsql: for-in-array (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: final patch - plpgsql: for-in-array
|
Список | pgsql-hackers |
2010/11/18 Tom Lane <tgl@sss.pgh.pa.us>: > 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. > yes, this argument is correct - but we can rearange a parser rules related to FOR statement. It can be solved. > 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. we talked about it last time - and I respect it - syntax is FOR IN >>>ARRAY<<< expression > > 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 Pavel > regards, tom lane >
В списке pgsql-hackers по дате отправления: