Re: hstore ==> and deprecate =>
От | Robert Haas |
---|---|
Тема | Re: hstore ==> and deprecate => |
Дата | |
Msg-id | AANLkTilY4qSR0x6c1zFLp-rtdeCE7Q41kPF5CHSLIF8d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: hstore ==> and deprecate => (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: hstore ==> and deprecate =>
|
Список | pgsql-hackers |
On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote: > Greg Stark <gsstark@mit.edu> writes: >> On Tue, Jun 8, 2010 at 8: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. >> >> I don't think we can throw warnings for DML except in the most dire >> circumstances. > > What about a WARNING at CREATE OPERATOR time? That's what the patch I sent already does. >>> 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? I'm not following this part. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: