Re: WIP: default values for function parameters
От | Pavel Stehule |
---|---|
Тема | Re: WIP: default values for function parameters |
Дата | |
Msg-id | 162867790812100526q14c2d241qd4b1de56a494e8d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: default values for function parameters (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: WIP: default values for function parameters
Re: WIP: default values for function parameters |
Список | pgsql-hackers |
2008/12/10 Bruce Momjian <bruce@momjian.us>: > Pavel Stehule wrote: >> > >> > How would a user recognise which of these are legal operator names? >> > >> > Incidentally -- EDB selling Oracle compatibility may put me in a questionable >> > position here -- the more Oracle incompatibilities in stock Postgres the >> > better for us. But afaik we don't emulate => anyways so that hardly matters. >> > If anything it shows how unimportant it is to worry about being compatible on >> > this front. >> > >> >> I don't search compatibility - just searching any good syntax. And >> Oracle used wide used syntax - from Ada, Perl. - It isn't Oracle >> patent or Oracle design. And named params hasn't big sense without >> default params. So now is time for speaking about it. >> >> look on ADA http://archive.adaic.com/standards/83rat/html/ratl-08-03.html >> >> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural. >> And it is my goal. > > Well, that is interesting, but in SQL we already use 'AS' in most places > where we want to assign a label to a value, so it seems AS is more > logical for SQL at this point. Question is - what is label - is it parameter name or some other value? Every output in SQL has default label - column name, or some default. And we use "AS" for change this default label. So using AS for param names is bad idea. Please, show me other case. > > The problem with a GUC is that when it is changed it breaks things and > it might be set in a dump file but not in postgresql.conf; there is a > long list of problems we have encountered when changing SQL semenatics > via GUC, autocommit being one of them. ofcourse, users have to use own mind - but it not break postgresql using. GUC allow implement new feature in some steps. Actually it's used for standard literals, and I don't know about any problems. Autocommit is different case - it's invisible but important change. Named params change syntax and impact is much more less than moving tsearch2 to core. regards Pavel Stehule > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + >
В списке pgsql-hackers по дате отправления: