2010/5/27 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > On 27/05/10 02:09, alvherre wrote: >> >> 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. > > AFAIU, the standard doesn't say anything about named parameters. Oracle uses > =>, but as you said, that's ambiguous with the => operator. > > +1 for FOR. >
I don't see any advantage of "FOR". We can change ir to support new standard or don't change it. Pavel > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
