From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, Decibel! <decibel(at)decibel(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal sql: labeled function params |
Date: | 2008-08-17 22:24:59 |
Message-ID: | 603c8f070808171524te28290by24514303f237601e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Actually the most "natural" syntax to me is just f(name=value) similar
> to how UPDATE does it. It has the added benefit of _not_ forcing us to
> make a operator reserved (AFAIK "=" can't be used to define new ops)
The problem with this is that
SELECT foo(a = b)
...is already valid syntax. It means compare a with b and pass the
resulting boolean to foo. I'm almost positive that changing this
would break all kinds of existing code (and probably create a lot of
grammar problems too). It's not an issue with SET because in that
case the "name=" part of the syntax is required rather than optional.
Any other operator you pick is going to have this same problem unless
it's already impossible to use that operator as part of an expression.
For that reason, while I'm not convinced of the value of the feature,
if we're going to support it then ISTM that expr AS label is the way
to go. That also has the advantage of being consistent with the
syntax for table and column aliasing.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2008-08-17 22:49:24 | Re: Overhauling GUCS |
Previous Message | Greg Smith | 2008-08-17 22:12:50 | Re: Overhauling GUCS |