Re: hstore ==> and deprecate => - Mailing list pgsql-hackers

From Robert Haas
Subject Re: hstore ==> and deprecate =>
Date
Msg-id AANLkTikq3c9zfEwbIetTzYNuq5yEahQvwyFGHZYM85GG@mail.gmail.com
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: hstore ==> and deprecate =>
Re: hstore ==> and deprecate =>
List pgsql-hackers
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release.  Attached is a patch to implement ==> as an alternative
>> operator name for hstore, and to make the backend throw a warning when
>> => is used as an operator name.
>>
>> One wart is that => is used not only as a SQL-level operator, but also
>> by hstore_in() when interpreting hstore-type literals, and by
>> hstore_out() when generating them.  My gut feeling is that we should
>> leave this part alone and only muck with the SQL operator, but perhaps
>> someone will care to argue the point.
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php
>
> hm.  any chance of a  shorter operator, like '#'?  I kinda agree that
> hstore_in and the operator don't have to be the same, but requiring
> three letter token for the two most high traffic operations w/hstore
> seems off to me.
>
> # is currently used for bitwise xor/geo

I'm happy to do whatever the consensus is.  I thought it would be
easier to remember if the two operators were spelled at least somewhat
similarly, but I just work here.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: _bt_parent_deletion_safe() isn't safe
Next
From: Pavel Stehule
Date:
Subject: Re: hstore ==> and deprecate =>