On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > 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?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
