Re: functional call named notation clashes with SQL feature

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> alvherre <alvherre(at)commandprompt(dot)com> writes:
>> 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.
>
> "Sucks" is not the word; "utterly unacceptable" is the word.  Having an
> expression mean different things depending on context is a recipe for
> unbelievable nightmares.  Can you imagine dealing with that in a query
> generator for example?  Or even ruleutils.c?
>
> If we go with the spec's syntax I think we'd have no realistic choice
> except to forbid => altogether as an operator name.  (And no, I'm not
> for that.)

I suppose the most painful thing about doing that is that it would
break hstore. Are there other commonly-used modules that rely on =>
as an operator name?

In spite of the difficulties, I'm reluctant to give up on it. I
always thought that the "AS" syntax was a crock and I'm not eager to
invent another crock to replace it. Being compatible with the SQL
standard and with Oracle is not to be taken lightly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company