hstore ==> and deprecate =>
in [PgSql]
|
From: Greg Stark on 9 Jun 2010 06:41 On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(a)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. In an OLTP system with high throughput a warning would fill the logs quickly, effectively making it impossible to use the syntax being warned about. If we're willing to do that we would just use an ERROR anyways which I don't think we're willing to do. People might need a transition period when they still use => because they need to write code which will work with either old or new versions. > 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. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Jun 2010 06:51 On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark <gsstark(a)mit.edu> wrote: > On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(a)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. The patch doesn't. >> 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. Sure, me too, but I think this is the best we can do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 9 Jun 2010 06:53 Greg Stark <gsstark(a)mit.edu> writes: > On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Jun 2010 07:09 On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine(a)hi-media.com> wrote: > Greg Stark <gsstark(a)mit.edu> writes: >> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 9 Jun 2010 09:06
Robert Haas <robertmhaas(a)gmail.com> writes: >> What about a WARNING at CREATE OPERATOR time? > > That's what the patch I sent already does. Great :) I read comments in the email instead of the commit… > I'm not following this part. I'm wondering if deprecating => as an SQL operator, we should too deprecate its usage in input text for hstore. I don't think so. -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |