From: | alvherre <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: functional call named notation clashes with SQL feature |
Date: | 2010-05-26 23:09:21 |
Message-ID: | 1274915069-sup-2440@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2010-05-26 23:09:25 | Re: Exposing the Xact commit order to the user |
Previous Message | Greg Stark | 2010-05-26 23:04:49 | Re: primary/secondary/master/slave/standby |