hstore ==> and deprecate =>

On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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.

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.

http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php

hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

merlin

On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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.

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.

http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php

hm.  any chance of a  shorter operator, like '#'?  I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

I'm happy to do whatever the consensus is. I thought it would be
easier to remember if the two operators were spelled at least somewhat
similarly, but I just work here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

2010/6/8 Merlin Moncure <mmoncure@gmail.com>:

On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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.

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.

http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php

hm.  any chance of a  shorter operator, like '#'?  I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

I am for Robert's proposal - ===> is one char longer - but
significantly readable

Regards

Pavel

p.s. I hope so in 9.1 will be complete hstore module marked as deprecated

Pavel Stehule <pavel.stehule@gmail.com> writes:

p.s. I hope so in 9.1 will be complete hstore module marked as deprecated

Really? And replaced with what? And why wouldn't the replacement use
the same operator names?

regards, tom lane

Tom Lane wrote:

Pavel Stehule <pavel.stehule@gmail.com> writes:

p.s. I hope so in 9.1 will be complete hstore module marked as deprecated

Really? And replaced with what? And why wouldn't the replacement use
the same operator names?

Yeah. I'll be looking for throats to cut if that happens. I have several
apps that use it extensively. If anything, I want it brought into core -
it has wide ranging usefulness.

cheers

andrew

On Jun 8, 2010, at 15:38 , Robert Haas wrote:

On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

I'm happy to do whatever the consensus is. I thought it would be
easier to remember if the two operators were spelled at least somewhat
similarly, but I just work here.

Perhaps
->
Would a colon work?

(That's enough bikeshedding for me.)

Michael Glaesemann
grzm seespotcode net

On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann <grzm@seespotcode.net> wrote:

On Jun 8, 2010, at 15:38 , Robert Haas wrote:

On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

hm.  any chance of a  shorter operator, like '#'?  I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

I'm happy to do whatever the consensus is.  I thought it would be
easier to remember if the two operators were spelled at least somewhat
similarly, but I just work here.

Perhaps
->

That's already in use to mean something else.

Would a colon work?

Nope.

ERROR: syntax error at or near ":"

(That's enough bikeshedding for me.)

Test first, then post? :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Jun 8, 2010, at 16:17 , Robert Haas wrote:

(That's enough bikeshedding for me.)

Test first, then post? :-)

What? :) If I was productively contributing, I wouldn't be bikeshedding, now would I?

Michael Glaesemann
grzm seespotcode net

On Jun 8, 2010, at 12:34 PM, Merlin Moncure wrote:

hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.

# is currently used for bitwise xor/geo

Not at all the same.

What about ~> ?

Best,

David

2010/6/8 Tom Lane <tgl@sss.pgh.pa.us>:

Pavel Stehule <pavel.stehule@gmail.com> writes:

p.s. I hope so in 9.1 will be complete hstore module marked as deprecated

Really?  And replaced with what?  And why wouldn't the replacement use
the same operator names?

We talked about integrated hash tables support.

regards

Pavel

On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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

On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark <gsstark@mit.edu> wrote:

On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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

Greg Stark <gsstark@mit.edu> writes:

On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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

On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:

Greg Stark <gsstark@mit.edu> writes:

On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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

Robert Haas <robertmhaas@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

On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:

Robert Haas <robertmhaas@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.

I don't think so, either. The most someone might want to do is make
==> work wherever => does now, but I wouldn't want to start monkeying
with that without some input from Andrew Gierth; and I don't think
it's a stop-ship issue for 9.0.

Unless there is more than one vote for some alternative other than
what I've done here (which so far there isn't), I'm going to add some
docs to this patch and commit it later today. Because the SQL
committee has standardized an incompatible syntax, there are no
perfect alternatives here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

"Robert" == Robert Haas <robertmhaas@gmail.com> writes:

Robert> I don't think so, either. The most someone might want to do
Robert> is make ==> work wherever => does now, but I wouldn't want to
Robert> start monkeying with that without some input from Andrew
Robert> Gierth; and I don't think it's a stop-ship issue for 9.0.

I'd really like to find a better operator name than ==>. But I'm not
convinced one exists.

While I don't like the inconsistency between ==> or whatever and the use
of => in type input and output, I regard the text representation as being
much harder to change safely, since client code will be parsing it. In this
case the inconsistency seems like a much smaller problem than changing the
text representation.

--
Andrew (irc:RhodiumToad)

Robert Haas <robertmhaas@gmail.com> writes:

+ if (!strcmp(oprName, "=>"))

BTW, project standard is to spell that like

+ if (strcmp(oprName, "=>") == 0)

The other way looks confusingly like a "not equal" test.

+ (errmsg("The use of => as an operator name is deprecated and may be disallowed in a future release.")));

Also, this doesn't follow message style guidelines. Possibly better:

errmsg("=> is deprecated as an operator name"),
errdetail("This name may be disallowed altogether in future versions of PostgreSQL.")

regards, tom lane

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

I'd really like to find a better operator name than ==>. But I'm not
convinced one exists.

I agree.

While I don't like the inconsistency between ==> or whatever and the use
of => in type input and output, I regard the text representation as being
much harder to change safely, since client code will be parsing it. In this
case the inconsistency seems like a much smaller problem than changing the
text representation.

Perhaps it would be sane to make hstore_in accept either => or ==>, but
not change hstore_out (for now)?

regards, tom lane