Re: proposal sql: labeled function params - Mailing list pgsql-hackers

From Robert Haas
Subject Re: proposal sql: labeled function params
Date
Msg-id 603c8f070808171524te28290by24514303f237601e@mail.gmail.com
Whole thread Raw
In response to Re: proposal sql: labeled function params  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: proposal sql: labeled function params  (Hannu Krosing <hannu@2ndQuadrant.com>)
List 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
valueof 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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Overhauling GUCS
Next
From: Steve Atkins
Date:
Subject: Re: Overhauling GUCS