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

From David E. Wheeler
Subject Re: hstore ==> and deprecate =>
Date
Msg-id C0D8C8D7-35D6-4F63-B36D-0C0BC2668C0A@kineticode.com
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
>>        hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which means it is not too late to reverse course.  So at this
> point the proposal is:
>
> * Leave the text => text operator alone for now, but deprecate it,
> and document/recommend the underlying hstore(text,text) function
> instead.
>
> * Get rid of the new text[] => text[] operator altogether, and
> provide/document only the underlying hstore(text[], text[])
> function.
>
> * Rename the new hstore => text[] operator to something else.
> (I'm not quite sold on Florian's & proposal, but don't have a
> better idea to offer offhand.)

+1

> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert().  Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore.  Can we do anything about this?  I don't think we want to revert
> to calling it tconvert().  Can we retroactively add the alternate name
> hstore() to previous versions, and suggest that people do that manually
> in existing hstore installations?

+1

Best,

David



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: hstore ==> and deprecate =>
Next
From: Dimitri Fontaine
Date:
Subject: Re: Command to prune archive at restartpoints