Greg Stark <gsst...@mit.edu> writes: > On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmh...@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? >> 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? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
