Re: WIP: default values for function parameters
От | Bruce Momjian |
---|---|
Тема | Re: WIP: default values for function parameters |
Дата | |
Msg-id | 200812101230.mBACU3500864@momjian.us обсуждение исходный текст |
Ответ на | Re: WIP: default values for function parameters ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: WIP: default values for function parameters
|
Список | pgsql-hackers |
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. 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. -- 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 по дате отправления: