Re: functional call named notation clashes with SQL feature

2010/5/27 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>