Re: hstore ==> and deprecate =>

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: hstore ==> and deprecate =>
Дата
Msg-id 28541.1276363263@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: hstore ==> and deprecate =>  ("David E. Wheeler" <david@kineticode.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade output directory
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_regress --use-existing does not appear in --help