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

From Tom Lane
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id 5930.1274923685@sss.pgh.pa.us
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: functional call named notation clashes with SQL feature
Re: functional call named notation clashes with SQL feature
Re: functional call named notation clashes with SQL feature
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Regression testing for psql
Next
From: Robert Haas
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages