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

From Tom Lane
Subject Re: hstore ==> and deprecate =>
Date
Msg-id 28541.1276363263@sss.pgh.pa.us
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: hstore ==> and deprecate =>  (Bruce Momjian <bruce@momjian.us>)
Re: hstore ==> and deprecate =>  ("David E. Wheeler" <david@kineticode.com>)
Re: hstore ==> and deprecate =>  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
"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.)


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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade output directory
Next
From: Bruce Momjian
Date:
Subject: Re: pg_regress --use-existing does not appear in --help