Re: proposal sql: labeled function params

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

In response to

Responses

Browse pgsql-hackers by date

  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