From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | daveg <daveg(at)sonic(dot)net> |
Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Decibel! <decibel(at)decibel(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Hannu Krosing" <hannu(at)2ndquadrant(dot)com> |
Subject: | Re: proposal sql: labeled function params |
Date: | 2008-08-24 05:59:46 |
Message-ID: | 162867790808232259j74359262jbaea7ded8b27add8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2008/8/24 daveg <daveg(at)sonic(dot)net>:
> On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
>> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>>
>> > Hello
>> >
>> > 2008/8/23 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> >>> If we're really worried about it we can have a GUC for a few versions
>> >>> that turns off named parameter assignment. But I don't think we
>> >>> should compromise the design on the theory that some folks might be
>> >>> using that as an operator *and* can't change their application to
>> >>> wrap it's use in ().
>> >>
>> >> Even if that were a reasonable strategy, you can't use GUC parameters to alter
>> >> parser behavior.
>> >
>> > I thing, so it's possible - in this case. We should transform named
>> > params to expr after syntax analyze.
>>
>> So for a bit of useless syntactic sugar we should introduce conflicts with
>> named parameters, conflicts with operators, introduce an un-sqlish syntax and
>> remove a feature users have already made use of and introduce backwards
>> compatibility issues for those users?
>>
>> At any point in this discussion has anyone explained why these labels would
>> actually be a good idea?
>
> I was missing that too. What is this for that makes it so compelling?
We are talking about two features (or three).
1. Named params (and defaults for params) - allows call function with
less params or with params in different order. - default parameters
allows decrease size of libraries (number of functions). Using default
without named params isn't comfortable (Firebird 2 do it), so we would
named params - named params specifies "some param has value ...",
developer shouldn't specify all params. sure - this functionality is
syntactic sugar and are not necessary - it only increase developer's
comfort.
2. Labeled params - put some knowledge (labels) about used params into
function. This is usable for mainly for serialization and dump
function (typical real case is SQL/XML). Other case are custom
functions in MySQL -
http://www.mysqludf.org/lib_mysqludf_json/index.php , sure - this
functionality is syntactic sugar and are not necessary - it only
increase developer's comfort. Labels params mean "for this value use
label". It same as standard keyword "AS" do it. Labeled params allows
explicit labels or implicit labels (column names).
Regards
Pavel Stehule
>
> -dg
>
>
> --
> David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
> If simplicity worked, the world would be overrun with insects.
>
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2008-08-24 06:00:20 | Re: Proposal: new border setting in psql |
Previous Message | D'Arcy J.M. Cain | 2008-08-24 05:42:18 | Re: Proposal: new border setting in psql |