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. +
>
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 |