Re: functional call named notation clashes with SQL feature

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

There don't seem to be any other contrib modules that define => as an
operator name, but I'm not sure what's out there on pgfoundry or
elsewhere. The bigger issue to me is not so much hstore itself as that
this is an awfully attractive operator name for anything container-ish.
Wasn't the JSON-datatype proposal using => for an operator at one stage?
(The current wiki page for it doesn't seem to reflect any such idea,
though.) And I think I remember Oleg & Teodor proposing such an
operator in conjunction with some GIN-related idea or other.

> 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.

Yeah, I know. Though this could end up being one of the bits of the
spec that we politely decline to follow, like upper-casing identifiers.
Still, it's a good idea to think again before we've set the release
in stone ...

regards, tom lane