From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: functional call named notation clashes with SQL feature |
Date: | 2010-05-31 19:06:38 |
Message-ID: | m2zkzfvqkh.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Krogh | 2010-05-31 19:52:40 | bitmap-index-scan faster than seq-scan on full-table-scan (gin index) |
Previous Message | Tom Lane | 2010-05-31 19:01:26 | Re: fillfactor gets set to zero for toast tables |