Re: hstore ==> and deprecate =>

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: hstore ==> and deprecate =>
Дата
Msg-id AANLkTiljDxL0GY147Jyn-ApY8B3RvxMBDoI1BZi1tUNw@mail.gmail.com
обсуждение исходный текст
Ответ на hstore ==> and deprecate =>  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: hstore ==> and deprecate =>  (Robert Haas <robertmhaas@gmail.com>)
Re: hstore ==> and deprecate =>  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: hstore ==> and deprecate =>  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
On Tue, Jun 8, 2010 at 3: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.
>
> 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.
>
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php

hm.  any chance of a  shorter operator, like '#'?  I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

merlin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: hstore ==> and deprecate =>
Следующее
От: Tom Lane
Дата:
Сообщение: Re: _bt_parent_deletion_safe() isn't safe