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

From Dimitri Fontaine
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id m2zkzfvqkh.fsf@hi-media.com
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> it's not important in this discussion. Important is using some usual
> symbol '=' or special symbol '=>'. Our syntax is probably only one
> possible solution in this moment (there are minimum controversy), bud
> semantic isn't best. Using same operator as assign statement uses can
> be messy. I don't know what is a true - you have to ask of ADA
> designers.

Well you assign a value to a named parameter, so I don't see the point.

Now SELECT myfunc(a := 1, b => 2); is about fine, the only point is that
the => operator looks good for associative things such as hstore, so
chances that it has been used are not so low.

I guess we could choose to go with := for 9.1 and revisit the =>
situation after the SQL standard has settled on the new version. Maybe
this move would even have some impact now that we have a voice over
there.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: fillfactor gets set to zero for toast tables
Next
From: Jesper Krogh
Date:
Subject: bitmap-index-scan faster than seq-scan on full-table-scan (gin index)