Re: functional call named notation clashes with SQL feature - Mailing list pgsql-hackers

From alvherre
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id 1274915069-sup-2440@alvh.no-ip.org
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: functional call named notation clashes with SQL feature
Re: functional call named notation clashes with SQL feature
Re: functional call named notation clashes with SQL feature
List pgsql-hackers
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:

> I think we should fix it now.  Quick thought: maybe we could use FOR 
> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's 
> mechanism for this is 'paramname => value', but I think that has 
> problems because of our possibly use of => as an operator - otherwise 
> that would be by far the best way to go.

I think we were refraining from => because the standard didn't specify
this back then -- AFAIU this was introduced very recently.  But now that
it does, and that the syntax we're implementing conflicts with a
different feature, it seems wise to use the standard-mandated syntax.

The problem with the => operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice.  Perhaps we could allow "=>" to resolve as the
operator for the case the user really needs to use it; or a
schema-qualified operator.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Exposing the Xact commit order to the user
Next
From: Heikki Linnakangas
Date:
Subject: Re: Synchronization levels in SR