On Wed, May 26, 2010 at 8:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > alvherre <alvhe...@commandprompt.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
