[HACKERS] deprecating =, take two
By consensus, we have removed the new-to-9.0 operator text[] = text[] and renamed the hstore = text[] operator. (The current name is %, but there is some discussion of %, some yet other name, or getting rid of it altogether; please comment on that thread if you wish to weigh in.) This means that the only remaining = operator in CVS is the text = text operator which constructs a single-element hstore, which has been around since 8.2. In lieu of providing a substitute operator, Tom Lane proposed that we simply encourage people to use the hstore(text, text) function which does the same thing: http://archives.postgresql.org/pgsql-hackers/2010-06/msg00711.php Per that email, and subsequent concurrence, here is a series of patches which does the following: 1. In CVS HEAD, document the hstore(text, text) function and adjust CREATE OPERATOR to throw a warning when = is used as an operator name, using the wording previously suggested by Tom. 2. In the back branches, add an hstore(text, text) function. These branches already have a tconvert(text, text) function which does the same thing, but the consensus seemed to be that we do not want to go back to the name tconvert() for this functionality, and that back-patching the new name was preferable. 3. In 8.4 and 8.3, also add hstore(text, text) to the documentation. 8.2 appears to have no contrib documentation. Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company hstore_82.patch Description: Binary data hstore_83.patch Description: Binary data hstore_84.patch Description: Binary data hstore_90.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
On Jun 21, 2010, at 9:20 AM, Robert Haas wrote: Per that email, and subsequent concurrence, here is a series of patches which does the following: 1. In CVS HEAD, document the hstore(text, text) function and adjust CREATE OPERATOR to throw a warning when = is used as an operator name, using the wording previously suggested by Tom. 2. In the back branches, add an hstore(text, text) function. These branches already have a tconvert(text, text) function which does the same thing, but the consensus seemed to be that we do not want to go back to the name tconvert() for this functionality, and that back-patching the new name was preferable. 3. In 8.4 and 8.3, also add hstore(text, text) to the documentation. 8.2 appears to have no contrib documentation. +1 I was just about to email asking where this was. Glad I checked for new mail first. :-) Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. So will the CREATE OPERATOR code be updated to issue the warning, rather than just for the case of hstore's = operator? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010: Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. Maybe this is just a matter of semantics, but I thought we were going to deprecate = in 9.0 so that people started to avoid its use altogether. Why wait till 9.1 to recommend avoidance? I had imagined that 9.1 was going to ban = altogether. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
On Mon, Jun 21, 2010 at 12:40 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010: Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. Maybe this is just a matter of semantics, but I thought we were going to deprecate = in 9.0 so that people started to avoid its use altogether. Why wait till 9.1 to recommend avoidance? I had imagined that 9.1 was going to ban = altogether. Sorry, bad phrasing on my part. Your understanding matches mine. -- 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
Re: [HACKERS] deprecating =, take two
On Mon, Jun 21, 2010 at 12:37 PM, David E. Wheeler da...@kineticode.com wrote: Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. So will the CREATE OPERATOR code be updated to issue the warning, rather than just for the case of hstore's = operator? Yes. -- 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
Re: [HACKERS] deprecating =, take two
Robert Haas robertmh...@gmail.com writes: Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. Two documentation comments: 1. Perhaps, rather than + The literal=gt;/ operator is deprecated and may be removed in a + future release. The use of the literalhstore(text, text)/literal + function is recommended as an alternative. write + The literal=gt;/ operator is deprecated and will be removed in a + future release. Use the literalhstore(text, text)/literal + function instead. in particular, s/may/will/ and avoid passive voice in the second sentence. 2. The 8.4 and 8.3 doc patches should include this same paragraph. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Barring vigorous objections, I will apply these tomorrow so that we can consider deprecating = as an operator name in 9.1, for better compliance with the SQL standard. Two documentation comments: 1. Perhaps, rather than + The literal=gt;/ operator is deprecated and may be removed in a + future release. The use of the literalhstore(text, text)/literal + function is recommended as an alternative. write + The literal=gt;/ operator is deprecated and will be removed in a + future release. Use the literalhstore(text, text)/literal + function instead. in particular, s/may/will/ and avoid passive voice in the second sentence. Avoiding the passive voice is a good idea, and I like your suggested phrasing. I'm reluctant to say what we will do in a future release because we don't always do what we claim we'll do. For example, we're planning to remove contrib/xml2 in 8.4. http://developer.postgresql.org/pgdocs/postgres/xml2.html Still, I haven't heard too many arguments against disallowing = as an operator, so perhaps it's safe to bank on it actually happening in this case? 2. The 8.4 and 8.3 doc patches should include this same paragraph. OK. -- 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
Re: [HACKERS] deprecating =, take two
Robert Haas robertmh...@gmail.com writes: By consensus, we have removed the new-to-9.0 operator text[] = text[] and renamed the hstore = text[] operator. (The current name is %, but there is some discussion of %, some yet other name, or getting rid of it altogether; please comment on that thread if you wish to weigh in.) Hey, you're asking for bikesheding! % would be my choice too. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
On Mon, Jun 21, 2010 at 1:46 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: Robert Haas robertmh...@gmail.com writes: By consensus, we have removed the new-to-9.0 operator text[] = text[] and renamed the hstore = text[] operator. (The current name is %, but there is some discussion of %, some yet other name, or getting rid of it altogether; please comment on that thread if you wish to weigh in.) Hey, you're asking for bikesheding! % would be my choice too. The point was that if you want to bikeshed, please do it on the OTHER thread, not this one. :-) -- 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
Re: [HACKERS] deprecating =, take two
Robert Haas robertmh...@gmail.com writes: On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: in particular, s/may/will/ and avoid passive voice in the second sentence. Avoiding the passive voice is a good idea, and I like your suggested phrasing. I'm reluctant to say what we will do in a future release because we don't always do what we claim we'll do. True. Still, I haven't heard too many arguments against disallowing = as an operator, so perhaps it's safe to bank on it actually happening in this case? AFAICS, the only way we won't do it is if the SQL committee reverses field on the syntax they're using. I'm not going to promise that it will change in 9.1 --- we might wait longer --- but once = is official standard syntax the pressure to do it will be high. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] deprecating =, take two
Robert Haas robertmh...@gmail.com writes: The point was that if you want to bikeshed, please do it on the OTHER thread, not this one. :-) Ouch, asking for bikeshed and understanding what you read around… I call that a trap ;) -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
