Skip site navigation (1) Skip section navigation (2)

Re: functional call named notation clashes with SQL feature

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, alvherre <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: functional call named notation clashes with SQL feature
Date: 2010-05-27 06:55:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/5/27 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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 ...
> Perhaps one idea would be to:
> 1. Invent a new crock for now.
> 2. Add a duplicate version of the hstore => operator with a different name.
> 3. Emit a warning whenever an operator called => is created.
> 4. Document that beginning in PG 9.1, we will no longer support => as
> an operator name.



> That's still going to cause a fair amount of pain, but certainly less
> if we decide it now rather than later.
> --
> Robert Haas
> EnterpriseDB:
> The Enterprise Postgres Company
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-05-27 07:09:16
Subject: Re: Synchronization levels in SR
Previous:From: KaiGai KoheiDate: 2010-05-27 06:55:31
Subject: [RFC] Security label support

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group