Re: WIP: default values for function parameters

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Grzegorz Jaskiewicz" <gj(at)pointblue(dot)com(dot)pl>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Subject: Re: WIP: default values for function parameters
Date: 2008-12-10 13:26:57
Message-ID: 162867790812100526q14c2d241qd4b1de56a494e8d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2008/12/10 Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2008-12-10 13:36:09 Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Previous Message Heikki Linnakangas 2008-12-10 13:16:16 Re: PostgreSQL 8.3.4 reproducible crash