On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> On Tue, Jun 8, 2010 at 8: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.
>>
>> 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