Thread: 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
Attachment
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
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 <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Jun 21, 2010 at 12:40 PM, Alvaro Herrera <alvherre@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
On Mon, Jun 21, 2010 at 12:37 PM, David E. Wheeler <david@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
Robert Haas <robertmhaas@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>=></> operator is deprecated and may be removed in a
> + future release. The use of the <literal>hstore(text, text)</literal>
> + function is recommended as an alternative.
write
> + The <literal>=></> operator is deprecated and will be removed in a
> + future release. Use the <literal>hstore(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
On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@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>=></> operator is deprecated and may be removed in a >> + future release. The use of the <literal>hstore(text, text)</literal> >> + function is recommended as an alternative. > > write > >> + The <literal>=></> operator is deprecated and will be removed in a >> + future release. Use the <literal>hstore(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
Robert Haas <robertmhaas@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
On Mon, Jun 21, 2010 at 1:46 PM, Dimitri Fontaine <dfontaine@hi-media.com> wrote: > Robert Haas <robertmhaas@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
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane <tgl@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
Robert Haas <robertmhaas@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