Re: hstore ==> and deprecate =>

On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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.
>>
>> I don't think we can throw warnings for DML except in the most dire
>> circumstances.
>
> What about a WARNING at CREATE OPERATOR time?

That's what the patch I sent already does.

>>> 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.
>>
>> I hate these kinds of inconsistencies. I would prefer both operators
>> be consistent.
>
> dim=# select 'foo' => 'bar', 'foo => bar'::hstore;
>   ?column?   |    hstore
> --------------+--------------
>  "foo"=>"bar" | "foo"=>"bar"
> (1 ligne)
>
> Well it's not an operator in the second case, it's part of the input
> "language" of the datatype. So consistency would be good enough if we
> had both the legacy input syntax support and the new one, right?

I'm not following this part.

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