Re: hstore ==> and deprecate =>

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: hstore ==> and deprecate =>
Date: 2010-06-09 10:53:43
Message-ID: 87hblcmq88.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

>> 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?

Regards,
--
dim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-06-09 10:54:51 walwriter not closing old files
Previous Message Robert Haas 2010-06-09 10:51:41 Re: hstore ==> and deprecate =>