From: Alvaro Herrera on
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(a)commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
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
On Mon, Jun 21, 2010 at 12:40 PM, Alvaro Herrera
<alvherre(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on
On Mon, Jun 21, 2010 at 12:37 PM, David E. Wheeler <david(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Robert Haas <robertmhaas(a)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 <literal>hstore(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 <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

--
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
On Mon, Jun 21, 2010 at 1:46 PM, Dimitri Fontaine
<dfontaine(a)hi-media.com> wrote:
> Robert Haas <robertmhaas(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers