Re: functional call named notation clashes with SQL feature
От | Jan Wieck |
---|---|
Тема | Re: functional call named notation clashes with SQL feature |
Дата | |
Msg-id | 4C08692A.9060003@Yahoo.com обсуждение исходный текст |
Ответ на | Re: functional call named notation clashes with SQL feature (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: functional call named notation clashes with SQL feature
|
Список | pgsql-hackers |
On 5/27/2010 11:52 PM, Andrew Dunstan wrote: > > Bruce Momjian wrote: >> Peter Eisentraut wrote: >> >>> On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: >>> >>>>> I think we should fix it now. Quick thought: maybe we could use >>>>> >>>> FOR >>>> >>>>> instead of AS: select myfunc(7 for a, 6 for b); >>>>> >>>> I'm afraid FOR doesn't work either; it'll create a conflict with the >>>> spec-defined SUBSTRING(x FOR y) syntax. >>>> >>> How about >>> >>> select myfunc(a := 7, b := 6); >>> >> >> One concern I have is that in PL/pgSQL, := and = behave the same, while >> in SQL, they would not. That might cause confusion. >> >> > > That is a sad wart that we should never have done, IMNSHO (it was before > my time or I would have objected ;-) ). But beyond that, = is an > operator in SQL and := is never an operator, IIRC. As far as I can tell, this was already in the code when Bruce moved it into core as -r1.1 on my behalf (before I had commit privileges). I do not recall if the = as alternative to := was my idea or not. But I'm willing to take the blame for it because it dates back to a time where convenience seemed important. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin
В списке pgsql-hackers по дате отправления: