Re: WIP: default values for function parameters - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: WIP: default values for function parameters
Date
Msg-id 162867790812100526q14c2d241qd4b1de56a494e8d@mail.gmail.com
Whole thread Raw
In response to Re: WIP: default values for function parameters  (Bruce Momjian <bruce@momjian.us>)
Responses Re: WIP: default values for function parameters
Re: WIP: default values for function parameters
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PostgreSQL 8.3.4 reproducible crash
Next
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)