Re: hstore ==> and deprecate =>

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

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

On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)com> wrote:
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)com>:
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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

>
> # is currently used for bitwise xor/geo
>
> merlin
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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(dot)stehule(at)gmail(dot)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(at)gmail(dot)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(at)seespotcode(dot)net> wrote:
> On Jun 8, 2010, at 15:38 , Robert Haas wrote:
>> On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

>                        regards, tom lane
>

On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)mit(dot)edu> wrote:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)mit(dot)edu> writes:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)hi-media(dot)com> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)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(at)hi-media(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)tao11(dot)riddles(dot)org(dot)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

On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:

> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> I'd really like to find a better operator name than ==>. But I'm not
>> convinced one exists.
>
> I agree.

+1

No one liked my suggestion of ~> ? Too similar to -> ? Other ideas:

'foo' :> 'bar'

'foo' @> 'bar'

'foo' #> 'bar'

'foo' &> 'bar'

'foo' *> 'bar'

'foo' +> 'bar'

'foo' > 'bar'

'bar' <= 'foo'

I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.

Hey, why not Unicode?

'bar' ➡ 'foo'

;-)

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

+1

David

On Wed, Jun 9, 2010 at 12:54 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
>> Perhaps it would be sane to make hstore_in accept either => or ==>, but
>> not change hstore_out (for now)?
>
> +1

Anyone want to take a crack at coding that? I took a brief look at
the code but it looked a bit intimidating at first glance.

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

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.

Colon was removed from the set of allowed operator-name characters years
ago. There are conflicts with various usages (ecpg & psql variables).
This is actually a place where the current := behavior could cause some
issues, though I'm not aware of any at the moment.

regards, tom lane

On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:

>> I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.
>
> Colon was removed from the set of allowed operator-name characters years
> ago. There are conflicts with various usages (ecpg & psql variables).
> This is actually a place where the current := behavior could cause some
> issues, though I'm not aware of any at the moment.

Oh, that's a shame.

In that case, how about:

'foo' >> 'bar'

Best,

David

On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name characters years
>> ago.  There are conflicts with various usages (ecpg & psql variables).
>> This is actually a place where the current := behavior could cause some
>> issues, though I'm not aware of any at the moment.
>
> Oh, that's a shame.
>
> In that case, how about:
>
>  'foo' >> 'bar'

Well, that doesn't look much like an arrow, at least not to me...

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

On Jun 9, 2010, at 10:33 AM, Robert Haas wrote:

> Well, that doesn't look much like an arrow, at least not to me...

It's a pointer, though. Not in the C sense, of course. But I often use » for "read more" style links in HTML. Its the same idea: move from this to that.

Anyway, for comparison's purpose:

'foo' ==> 'bar'
'foo' >> 'bar'

Pity about :>.

Best,

David

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> 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.

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

I'd be happy with that.

--
Andrew (irc:RhodiumToad)

On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name characters years
>> ago.  There are conflicts with various usages (ecpg & psql variables).
>> This is actually a place where the current := behavior could cause some
>> issues, though I'm not aware of any at the moment.
>
> Oh, that's a shame.
>
> In that case, how about:
>
>  'foo' >> 'bar'

+1

merlin

On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
> > Perhaps
> > ->
>
> That's already in use to mean something else.

Btw., the SQL standard also defines -> for something else, so if you
wanted to be really visionary, you could deprecate that one as an
operator at the same time.

On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
>> > Perhaps
>> > ->
>>
>> That's already in use to mean something else.
>
> Btw., the SQL standard also defines -> for something else, so if you
> wanted to be really visionary, you could deprecate that one as an
> operator at the same time.

Ouch. What does it define it to mean?

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

On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote:
> On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
> >> > Perhaps
> >> > ->
> >>
> >> That's already in use to mean something else.
> >
> > Btw., the SQL standard also defines -> for something else, so if you
> > wanted to be really visionary, you could deprecate that one as an
> > operator at the same time.
>
> Ouch. What does it define it to mean?

Similar to C: Dereferencing a reference and accessing a member.

On tis, 2010-06-08 at 15:38 -0400, Robert Haas wrote:
> 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.

How about no operator at all? It won't be as cool to read, but
consider, the arguments are text and text, not involving any hstore type
at all, so whatever operator you choose is in practice blocked from
everyone everywhere. No one could ever implement another key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.

Why not just write:

hstore('this', 'that')
hstore(key := 'this', value := 'that')

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>> Btw., the SQL standard also defines -> for something else, so if you
>>> wanted to be really visionary, you could deprecate that one as an
>>> operator at the same time.
>>
>> Ouch. What does it define it to mean?

> Similar to C: Dereferencing a reference and accessing a member.

But a reference would be a datatype no? So we could just regard that as
an ordinary operator. I don't see a reason why it would conflict with
use of the same operator name for other datatypes (unlike the situation
with =>).

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> How about no operator at all? It won't be as cool to read, but
> consider, the arguments are text and text, not involving any hstore type
> at all, so whatever operator you choose is in practice blocked from
> everyone everywhere. No one could ever implement another key/value
> system that uses a similar interface. Or use the operator for anything
> else involving strings.

Yeah, that's a good point. Maybe we should just deprecate the operator
altogether.

regards, tom lane

On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:

>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> everyone everywhere. No one could ever implement another key/value
>> system that uses a similar interface. Or use the operator for anything
>> else involving strings.
>
> Yeah, that's a good point. Maybe we should just deprecate the operator
> altogether.

That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me.

Best,

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
>> Yeah, that's a good point. Maybe we should just deprecate the operator
>> altogether.

> That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me.

Less inconsistent, ITYM? But yeah, then we would have no reason to
fiddle with hstore_in, which is good.

regards, tom lane

On Jun 11, 2010, at 9:58 AM, Tom Lane wrote:

>> That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me.
>
> Less inconsistent, ITYM? But yeah, then we would have no reason to
> fiddle with hstore_in, which is good.

Yes, sorry.

David

On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> How about no operator at all?  It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> everyone everywhere.  No one could ever implement another key/value
>> system that uses a similar interface.  Or use the operator for anything
>> else involving strings.
>
> Yeah, that's a good point.  Maybe we should just deprecate the operator
> altogether.
>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

To repeat an earlier question (which was in turn repeating an earlier
question), would it be possible to do one of these, yielding '
"key"=>"this", "key2"=>"that" '::hstore :

hstore(key := 'this', key2 := 'that')
hstore(key => 'this', key2 => 'that')
hstore(row('this' AS key, 'that' AS key2))

In my opinion, it's important to find a reasonably elegant way to
express hstore literals (rather than something like
hstore(hstore_kvp('key', 'this'), hstore_kvp('key2', 'that')) )
because something so basic shouldn't be so difficult to work with.
It'd be a bonus if there was a general form for arbitrary named
parameters that new functions could opt-in on (in particular,
json_object :-) ).

This type of function could be created by saying something like:

CREATE FUNCTION hstore(NAMED) RETURNS hstore AS ...
-- NAMED would be a new argtype

Also, if a user needs to name a field from a variable, perhaps there
should be a syntax that allows it, such as:

hstore(pg_deref(var) => 'this', pg_deref(var2) => 'that')

If implementing pg_deref would be problematic in general, perhaps it
could initially just be supported in keys of functions like this.

Only if we allow for functions with named parameters in this fashion
would I say +1 for deprecating the => operator from hstore without a
replacement operator like ==> .

Joey Adams

Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> writes:
> To repeat an earlier question (which was in turn repeating an earlier
> question), would it be possible to do one of these, yielding '
> "key"=>"this", "key2"=>"that" '::hstore :

> hstore(key := 'this', key2 := 'that')
> hstore(key => 'this', key2 => 'that')
> hstore(row('this' AS key, 'that' AS key2))

The last of those is probably the easiest to get to. We already have
hstore_from_record:

contrib_regression=# select hstore(row('this', 'that'));
hstore
----------------------------
"f1"=>"this", "f2"=>"that"
(1 row)

and the only thing lacking is an easy way to specify the column names
associated with the anonymous record type. Extending the ROW()
construct with AS labels as suggested above might be a reasonable way.

regards, tom lane

On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> writes:
>> To repeat an earlier question (which was in turn repeating an earlier
>> question), would it be possible to do one of these, yielding '
>> "key"=>"this", "key2"=>"that" '::hstore  :
>
>> hstore(key := 'this', key2 := 'that')
>> hstore(key => 'this', key2 => 'that')
>> hstore(row('this' AS key, 'that' AS key2))
>
> The last of those is probably the easiest to get to.  We already have
> hstore_from_record:
>
> contrib_regression=# select hstore(row('this', 'that'));
>           hstore
> ----------------------------
>  "f1"=>"this", "f2"=>"that"
> (1 row)
>
> and the only thing lacking is an easy way to specify the column names
> associated with the anonymous record type.  Extending the ROW()
> construct with AS labels as suggested above might be a reasonable way.

+1

A couple of people were just requesting that very thing (ROW/AS) on
the IRC channel today. row() is a pretty useful mechanism and it
would be nice to have it more defensible vs. table changes.

merlin

On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >>> Btw., the SQL standard also defines -> for something else, so if you
> >>> wanted to be really visionary, you could deprecate that one as an
> >>> operator at the same time.
> >>
> >> Ouch. What does it define it to mean?
>
> > Similar to C: Dereferencing a reference and accessing a member.
>
> But a reference would be a datatype no? So we could just regard that as
> an ordinary operator. I don't see a reason why it would conflict with
> use of the same operator name for other datatypes (unlike the situation
> with =>).

The right side of the -> would be an identifier, like

(some expr yielding a ref)->attribute

or

objref->method(args)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
>> But a reference would be a datatype no? So we could just regard that as
>> an ordinary operator. I don't see a reason why it would conflict with
>> use of the same operator name for other datatypes (unlike the situation
>> with =>).

> The right side of the -> would be an identifier, like
> (some expr yielding a ref)->attribute
> or
> objref->method(args)

Yeah, but the *left* side still has to be a special datatype that
doesn't exist today. So we have at least some chance of not usurping
existing usages of the operator name. In principle you could have
transformAExprOp transform the left side and then check for this case
before trying to transform the right side.

(And in any case, I haven't noticed anybody expressing any interest
in implementing that part of the spec.)

But actually, there's another issue here: hstore defines not one but
three => operators:

text => text yields hstore (with 1 element)
text[] => text[] yields hstore (with N elements)
hstore => text[] yields hstore (subset)

It's reasonable to say that the first two are bad design, but I'm
a bit less willing to say that the last one is. What shall we
do with that?

regards, tom lane

On Jun 12, 2010, at 14:57 , Tom Lane wrote:
> But actually, there's another issue here: hstore defines not one but
> three => operators:
>
> text => text yields hstore (with 1 element)
> text[] => text[] yields hstore (with N elements)
> hstore => text[] yields hstore (subset)
>
> It's reasonable to say that the first two are bad design, but I'm
> a bit less willing to say that the last one is. What shall we
> do with that?

Hm, the last one seems to be more akin to
hstore - text yields hstore (key removed)
hstore - text[] yields hstore (keys in array removed)
hstore - hstore yields hstore (keys in hstore removed)

since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore.

Inspired by the already existing
hstore ?& text[] yields boolean (true if set of keys subset of array)
I suggest
hstore & text[]
as a replacement.

best regards,
Florian Pflug

On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:

>> hstore(key := 'this', key2 := 'that')
>> hstore(key => 'this', key2 => 'that')
>> hstore(row('this' AS key, 'that' AS key2))
>
> The last of those is probably the easiest to get to. We already have
> hstore_from_record:

Is not the first one simply a function with any number of named params?

Best,

David

On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote:

>> It's reasonable to say that the first two are bad design, but I'm
>> a bit less willing to say that the last one is. What shall we
>> do with that?
>
> Hm, the last one seems to be more akin to
> hstore - text yields hstore (key removed)
> hstore - text[] yields hstore (keys in array removed)
> hstore - hstore yields hstore (keys in hstore removed)

Well, no, the keys aren't removed: you get back an hstore with only those keys (the lhs is unchanged).

> since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore.
>
> Inspired by the already existing
> hstore ?& text[] yields boolean (true if set of keys subset of array)
> I suggest
> hstore & text[]
> as a replacement.

Yes, agreed.

That just leaves

text[] => text[] yields hstore (with N elements)

Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an

hstore(text[], text[])

Best,

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
>>> hstore(key := 'this', key2 := 'that')
>>> hstore(key => 'this', key2 => 'that')
>>> hstore(row('this' AS key, 'that' AS key2))
>>
>> The last of those is probably the easiest to get to. We already have
>> hstore_from_record:

> Is not the first one simply a function with any number of named params?

No, because the desire presumably would be to be able to use any set of
parameter names with that one function ... which absolutely flies in the
face of our current notion of what a parameter name means. You'd
essentially have to disable the ability to have function overloading.
(Which probably means it Ain't Happening.)

regards, tom lane

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
> hstore(text[], text[])

Oh --- now that I look, both that and the hstore => text[] one are new
in 9.0, which means it is not too late to reverse course. So at this
point the proposal is:

* Leave the text => text operator alone for now, but deprecate it,
and document/recommend the underlying hstore(text,text) function
instead.

* Get rid of the new text[] => text[] operator altogether, and
provide/document only the underlying hstore(text[], text[])
function.

* Rename the new hstore => text[] operator to something else.
(I'm not quite sold on Florian's & proposal, but don't have a
better idea to offer offhand.)

I notice that in 8.4 and before, the function underlying text => text
wasn't called hstore() but tconvert(). Which is going to be a serious
PITA for anyone who wants to write cross-version-compatible SQL using
hstore. Can we do anything about this? I don't think we want to revert
to calling it tconvert(). Can we retroactively add the alternate name
hstore() to previous versions, and suggest that people do that manually
in existing hstore installations?

regards, tom lane

Tom Lane wrote:
> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert(). Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore. Can we do anything about this? I don't think we want to revert
> to calling it tconvert(). Can we retroactively add the alternate name
> hstore() to previous versions, and suggest that people do that manually
> in existing hstore installations?

In general, I don't think we make enough use of supplying
backward-compatible SQL scripts to fix things, so +1. Let's use the
object-relational features we have to make things easier for users.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:

> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
>> hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which means it is not too late to reverse course. So at this
> point the proposal is:
>
> * Leave the text => text operator alone for now, but deprecate it,
> and document/recommend the underlying hstore(text,text) function
> instead.
>
> * Get rid of the new text[] => text[] operator altogether, and
> provide/document only the underlying hstore(text[], text[])
> function.
>
> * Rename the new hstore => text[] operator to something else.
> (I'm not quite sold on Florian's & proposal, but don't have a
> better idea to offer offhand.)

+1

> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert(). Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore. Can we do anything about this? I don't think we want to revert
> to calling it tconvert(). Can we retroactively add the alternate name
> hstore() to previous versions, and suggest that people do that manually
> in existing hstore installations?

+1

Best,

David

On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
>>         hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which means it is not too late to reverse course.  So at this
> point the proposal is:
>
> * Leave the text => text operator alone for now, but deprecate it,
> and document/recommend the underlying hstore(text,text) function
> instead.
>
> * Get rid of the new text[] => text[] operator altogether, and
> provide/document only the underlying hstore(text[], text[])
> function.
>
> * Rename the new hstore => text[] operator to something else.
> (I'm not quite sold on Florian's & proposal, but don't have a
> better idea to offer offhand.)
>
>
> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert().  Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore.  Can we do anything about this?  I don't think we want to revert
> to calling it tconvert().  Can we retroactively add the alternate name
> hstore() to previous versions, and suggest that people do that manually
> in existing hstore installations?

Here's a patch that removes the text[] => text[] operator - as
suggested above - and instead documents hstore(text[], text[]).
Barring objections, I will commit this and then start looking at the
other portions of this proposal.

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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> But actually, there's another issue here: hstore defines not one
Tom> but three => operators:

Tom> text => text yields hstore (with 1 element)
Tom> text[] => text[] yields hstore (with N elements)
Tom> hstore => text[] yields hstore (subset)

Tom> It's reasonable to say that the first two are bad design, but
Tom> I'm a bit less willing to say that the last one is. What shall
Tom> we do with that?

I added the second two primarily by analogy with the first; following
the existing pattern seemed to be the way to go at the time.

If the first (text => text) operator hadn't already been present when I
started looking at it, I'd probably have stuck to hstore() for all
construction methods rather than defining an operator. Creating operators
that take only existing builtin types is obviously a namespace problem in
that multiple independent modules might get into trouble by choosing the
same operators. Perhaps this should be formalized as some sort of style
guideline for module authors?

I'm happy with deprecating the first two => in favour of hstore() if
that is in line with general opinion. The hstore => text[] slice could
be replaced by another operator name; the existing name comes from the
analogy that (hstore -> text[]) returns the list of values, whereas
(hstore => text[]) returns both the keys and values.

--
Andrew (irc:RhodiumToad)

On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
> I'm happy with deprecating the first two => in favour of hstore() if
> that is in line with general opinion. The hstore => text[] slice could
> be replaced by another operator name; the existing name comes from the
> analogy that (hstore -> text[]) returns the list of values, whereas
> (hstore => text[]) returns both the keys and values.

So, I kind of like Florian Pflug's suggestion upthread of replacing
hstore => text by hstore & text[]. I think that's about as mnemonic
as we're likely to get, and it gels nicely with the hstore ?& text[]
operator, which tests whether all of the named keys are present in the
hstore.

Does anyone want to bikeshed further before I go do that?

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

On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:

> On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>> I'm happy with deprecating the first two => in favour of hstore() if
>> that is in line with general opinion. The hstore => text[] slice could
>> be replaced by another operator name; the existing name comes from the
>> analogy that (hstore -> text[]) returns the list of values, whereas
>> (hstore => text[]) returns both the keys and values.
>
> So, I kind of like Florian Pflug's suggestion upthread of replacing
> hstore => text by hstore & text[]. I think that's about as mnemonic
> as we're likely to get, and it gels nicely with the hstore ?& text[]
> operator, which tests whether all of the named keys are present in the
> hstore.
>
> Does anyone want to bikeshed further before I go do that?

Yeah. It actually doesn't make much sense to me. ?& is all about the keys and their presence, not the values. -> is a much better parallel, it being that it returns the keys in the rhs array. So I think something closer to it would be better. Some suggestions:

~>
<-
#>
+>

Ooh, I like +>, as being: give me more than -> does.

Best,

David

On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
>
>> On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
>> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>> I'm happy with deprecating the first two => in favour of hstore() if
>>> that is in line with general opinion. The hstore => text[] slice could
>>> be replaced by another operator name; the existing name comes from the
>>> analogy that (hstore -> text[]) returns the list of values, whereas
>>> (hstore => text[]) returns both the keys and values.
>>
>> So, I kind of like Florian Pflug's suggestion upthread of replacing
>> hstore => text by hstore & text[].  I think that's about as mnemonic
>> as we're likely to get, and it gels nicely with the hstore ?& text[]
>> operator, which tests whether all of the named keys are present in the
>> hstore.
>>
>> Does anyone want to bikeshed further before I go do that?
>
> Yeah. It actually doesn't make much sense to me. ?& is all about the keys and their presence, not the values. -> is a much better parallel, it being that it returns the keys in the rhs array. So I think something closer to it would be better.

Well, the idea is it's like logical-and - give me only those keys that
appear on both sides...

> Some suggestions:
>
>  ~>
>  <-
>  #>
>  +>
>
> Ooh, I like +>, as being: give me more than -> does.

If there is a critical mass of votes for one of these options, I'm
fine with whatever.

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

On Jun 15, 2010, at 6:58 PM, Robert Haas wrote:

> Well, the idea is it's like logical-and - give me only those keys that
> appear on both sides...

Yeah, but => doesn't return the keys, -> does. => returns an hstore.

> If there is a critical mass of votes for one of these options, I'm
> fine with whatever.

Put me down for +>.

Best,

David

On Tue, Jun 15, 2010 at 10:55 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 15, 2010, at 6:58 PM, Robert Haas wrote:
>
>> Well, the idea is it's like logical-and - give me only those keys that
>> appear on both sides...
>
> Yeah, but => doesn't return the keys, -> does. => returns an hstore.
>
>> If there is a critical mass of votes for one of these options, I'm
>> fine with whatever.
>
> Put me down for +>.

Since there are no other votes for that option (or, indeed, any other
option), I'm going to go with my original instinct and change hstore
=> text[] to hstore & text[]. Patch to do that is attached.

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

On Jun 16, 2010, at 4:24 PM, Robert Haas wrote:

>> Put me down for +>.
>
> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.

Damn. My other argument is that & looks like boolean or bitwise AND, so the return of an hstore might be unexpected. +> looks more like an arrow (sort of).

But it doesn't much matter, as long as it works.

Best,

David

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.

Um ... wait a minute. What happened to backwards compatibility?
I thought the idea was to deprecate => for a release or so, not kill it
on the spot.

regards, tom lane

On Jun 16, 2010, at 4:53 PM, Tom Lane wrote:

> Um ... wait a minute. What happened to backwards compatibility?
> I thought the idea was to deprecate => for a release or so, not kill it
> on the spot.

hstore => text[] is new in 9.0.

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jun 16, 2010, at 4:53 PM, Tom Lane wrote:
>> Um ... wait a minute. What happened to backwards compatibility?
>> I thought the idea was to deprecate => for a release or so, not kill it
>> on the spot.

> hstore => text[] is new in 9.0.

Wup, sorry, I read this as being the other operator. Nevermind ...

(FWIW, I share your dislike of & for this operator. I just haven't
got a better idea.)

regards, tom lane

On Jun 16, 2010, at 4:58 PM, Tom Lane wrote:

>> hstore => text[] is new in 9.0.
>
> Wup, sorry, I read this as being the other operator. Nevermind ...
>
> (FWIW, I share your dislike of & for this operator. I just haven't
> got a better idea.)

There aren't any very good choices. Possible correlates:

text[] key_slice := my_hstore -> ARRAY['foo', 'bar'];

bool has_keys := my_hstore ?& ARRAY['foo', 'bar'];

text[] keyvals := %% my_hstore;

text[] keyvals := %# my_hstore;

Frankly, %% and %# are closest, in a sense. But instead of an array, we want to get back an hstore. -> and ?& are correlates in that their RHSs are arrays.

Possible operators to get a slice of the hstore:

hstore slice := my_hstore +> ARRAY['foo', 'bar'];

hstore slice := my_hstore #> ARRAY['foo', 'bar'];

hstore slice := my_hstore &> ARRAY['foo', 'bar'];

hstore slice := my_hstore !> ARRAY['foo', 'bar'];

hstore slice := my_hstore *> ARRAY['foo', 'bar'];

hstore slice := my_hstore %> ARRAY['foo', 'bar'];

hstore slice := my_hstore @ ARRAY['foo', 'bar'];

hstore slice := my_hstore % ARRAY['foo', 'bar'];

hstore slice := my_hstore # ARRAY['foo', 'bar'];

hstore slice := my_hstore & ARRAY['foo', 'bar'];

hstore slice := my_hstore @# ARRAY['foo', 'bar'];

Maybe %> is good, in that it combines %% and ->, in a sense. Or #>, which kind of goes along with #=, which also returns an hstore.

Anyway, the more I look at it the less I care, as long as *something* works.

Best,

David

On Jun 17, 2010, at 2:56 , David E. Wheeler wrote:
> On Jun 16, 2010, at 4:58 PM, Tom Lane wrote:
>
>>> hstore => text[] is new in 9.0.
>>
>> Wup, sorry, I read this as being the other operator. Nevermind ...
>>
>> (FWIW, I share your dislike of & for this operator. I just haven't
>> got a better idea.)
>
> There aren't any very good choices.

Since there seems to be no consensus on this, maybe thats a sign that there shouldn't be an operator for this at all. I suggested & due due the similarities to ?&, but I can see why people object to that - mainly because it looks like an predicate, not like an operation on hstores.

How about turning it into a function
hstore hstore(hstore, text[])
instead?

Could also be hstore_restrict if people think naming it just hstore is ambiguous.

best regards,
Florian Pflug

> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.

If what that operator is doing is appending an array of text to an
Hstore, shouldn't we use || instead?

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Since there are no other votes for that option (or, indeed, any other
>> option), I'm going to go with my original instinct and change hstore
>> => text[] to hstore & text[].  Patch to do that is attached.
>
> If what that operator is doing is appending an array of text to an
> Hstore, shouldn't we use || instead?

It isn't. || already does what you're saying.

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

On 6/17/10 1:40 PM, Robert Haas wrote:
> On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> Since there are no other votes for that option (or, indeed, any other
>>> option), I'm going to go with my original instinct and change hstore
>>> => text[] to hstore & text[]. Patch to do that is attached.
>> If what that operator is doing is appending an array of text to an
>> Hstore, shouldn't we use || instead?
>
> It isn't. || already does what you're saying.

So what *does* it do?

OK, so after a brief poll on IRC, one reason you're not getting coherent
feedback on this is that few people understand the operators which
hstore 9.0 already uses and which are new for 9.0, let alone what new
operators are proposed for each thing. I know I've completely lost
track, particularly since doc patches haven't kept up with the code
changes. I've reread most of this thread and it doesn't help me.

On the other hand, maybe less feedback is less bikeshedding. You decide.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Jun 17, 2010, at 1:50 PM, Josh Berkus wrote:

>> It isn't. || already does what you're saying.
>
> So what *does* it do?

It returns an hstore that's effectively a slice of another hstore. From the docs (http://developer.postgresql.org/pgdocs/postgres/hstore.html):

'a=>1,b=>2,c=>3'::hstore => ARRAY['b','c','x']

Result is:

'"b"=>"2", "c"=>"3"'::hstore

Best,

David

On Thu, Jun 17, 2010 at 4:50 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 6/17/10 1:40 PM, Robert Haas wrote:
>> On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>>> Since there are no other votes for that option (or, indeed, any other
>>>> option), I'm going to go with my original instinct and change hstore
>>>> => text[] to hstore & text[].  Patch to do that is attached.
>>> If what that operator is doing is appending an array of text to an
>>> Hstore, shouldn't we use || instead?
>>
>> It isn't.  || already does what you're saying.
>
> So what *does* it do?
>
> OK, so after a brief poll on IRC, one reason you're not getting coherent
> feedback on this is that few people understand the operators which
> hstore 9.0 already uses and which are new for 9.0, let alone what new
> operators are proposed for each thing.  I know I've completely lost
> track, particularly since doc patches haven't kept up with the code
> changes.  I've reread most of this thread and it doesn't help me.
>
> On the other hand, maybe less feedback is less bikeshedding.  You decide.

Well, they are documented, so you can read up on them...

http://developer.postgresql.org/pgdocs/postgres/hstore.html

This isn't a critical issue in desperate need of community input; we
just need to resolve it one way or the other so we can move on to the
next thing. I'm still inclined to go ahead and apply the patch I
attached upthread, because that is less work for me than doing
anything else...

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

On 6/17/10 2:03 PM, David E. Wheeler wrote:
> On Jun 17, 2010, at 1:50 PM, Josh Berkus wrote:
>
>>> It isn't. || already does what you're saying.
>> So what *does* it do?
>
> It returns an hstore that's effectively a slice of another hstore. From the docs (http://developer.postgresql.org/pgdocs/postgres/hstore.html):

OK, hammered this out on IRC with several Hstore users, and I think the
best answer here is consistency. Both with the other hstore operators
and with other set types, such as intarray and ltree.

Currently for hstore, %% returns a flattened array and %# returns a
two-dimensional array. That means that it makes sense that the operator
which returns an hstore subset should be something based on %, either
%>, %% or just %.

I vote for % .

Stuff we discussed and discarded includes:

& for two reasons: (a) it looks like a predicate and (b) it's used as
"intersect" for intarray and ltree, and we might want to implement
intersect for hstore someday.

# because it's used as "index" for intarray, and thus should more
properly be a synonym for -> in hstore

+> because it looks like it ought to be some kind of special incrementor.

Using % would also mean that sometime in the future we can implement !%
as "elements NOT in this list" (i.e. ' a => 1, b => 2, c => 5' !% 'a, b'
== 'c => 5' )

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Currently for hstore, %% returns a flattened array and %# returns a
> two-dimensional array. That means that it makes sense that the operator
> which returns an hstore subset should be something based on %, either
> %>, %% or just %.

But %% and %# are prefix operators. Extrapolating from those to an
infix operator seems a bit thin. Nonetheless, something using % seems
better than something using &, for the other reasons you mention.

> I vote for % .

I'd vote for %>, out of those. Reason: the operator isn't commutative,
in fact left and right inputs aren't even the same datatype, so a glyph
that looks asymmetric seems more natural.

> Using % would also mean that sometime in the future we can implement !%
> as "elements NOT in this list" (i.e. ' a => 1, b => 2, c => 5' !% 'a, b'
> == 'c => 5' )

You can prepend ! to any operator name at all, so that's not much of
a differentiator.

regards, tom lane

On Jun 17, 2010, at 4:15 PM, Tom Lane wrote:

>> Using % would also mean that sometime in the future we can implement !%
>> as "elements NOT in this list" (i.e. ' a => 1, b => 2, c => 5' !% 'a, b'
>> == 'c => 5' )
>
> You can prepend ! to any operator name at all, so that's not much of
> a differentiator.

%!> then. :-)

David

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>> Currently for hstore, %% returns a flattened array and %# returns a
>> two-dimensional array. That means that it makes sense that the operator
>> which returns an hstore subset should be something based on %, either
>> %>, %% or just %.
>>
>
> But %% and %# are prefix operators. Extrapolating from those to an
> infix operator seems a bit thin. Nonetheless, something using % seems
> better than something using &, for the other reasons you mention.
>
>
>> I vote for % .
>>
>
> I'd vote for %>, out of those. Reason: the operator isn't commutative,
> in fact left and right inputs aren't even the same datatype, so a glyph
> that looks asymmetric seems more natural.
>
>

I think this bikeshed is going to be more paint than shed. However, I
just wondered about | as the operator. Think of the right hand operand
as a filter on the hstore, and a pipe seems to work.

Lots of operators aren't commutative. Arithmetic % for example ;-)

But honestly, I can live with just about anything.

cheers

andrew

On Thu, Jun 17, 2010 at 11:04 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> I vote for % .
>> I'd vote for %>, out of those.  Reason: the operator isn't commutative,
>> in fact left and right inputs aren't even the same datatype, so a glyph
>> that looks asymmetric seems more natural.
> Lots of operators aren't commutative. Arithmetic % for example ;-)

I've committed this as % -- if anyone cares about it enough to keep
arguing, we can change it again.

> I think this bikeshed is going to be more paint than shed.

You said it.

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

>> I vote for % .
>
> I'd vote for %>, out of those. Reason: the operator isn't commutative,
> in fact left and right inputs aren't even the same datatype, so a glyph
> that looks asymmetric seems more natural.

+1 on %>

(Frankly, as long as it isn't & or | I can live with it ... )

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Jun 18, 2010, at 10:03 AM, Josh Berkus wrote:

>> I'd vote for %>, out of those. Reason: the operator isn't commutative,
>> in fact left and right inputs aren't even the same datatype, so a glyph
>> that looks asymmetric seems more natural.
>
> +1 on %>

+1 from me, too.

Best,

David

On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> +1 from me, too.
>

1 isn't a valid character in a postgres operator

:P

--
greg

On Jun 18, 2010, at 11:20 AM, Greg Stark wrote:

>> +1 from me, too.
>>
>
> 1 isn't a valid character in a postgres operator

Dammit!

This reminds me, I wanted to ask one more thing:

We don't have a slice operator for arrays; would we be happy with %> being such an operator in a future version? And, does the spec say anything about array operators?

Best,

David

On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> We don't have a slice operator for arrays; would we be happy with %> being such an operator in a future version? And, does the spec say anything about array operators?
>

Personally, I don't find any of these proposals terribly intuitive.

You know we don't really need an operator at all. slice(hash,
array[1,2,3]) seems like not much typing overhead over hash %
array[1,2,3] and clearer to boot. The only real advantage to having
operators is for operators used to define opclasses. I can't see this
ever being used in such a circumstance (but perhaps I'm not
imaginative enough for GIST indexes these days) so unless there's a
clear analogy to some basic operator that makes code clearer I would
suggest it's not really buying us anything to define an operator name
at all.

--
greg

On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:

> How about turning it into a function
> hstore hstore(hstore, text[])
> instead?

I just searched through the 2008 spec for a slice/subset operator and came up empty. It seems to define a bunch of predicates for multisets, but not much for arrays.

And looking again at the options, I'm *okay* with %, but not keen on %> anymore (I could see a future where %> and <% it as complement @> and <@ by confirming the presence of keys in an hstore:

bool = hstore %> text[];

So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?

hstore = slice(hstore, text[]);

It'd be nice to have one for arrays, too:

anyarray[] = slice(anyarray[], int[]);

An operator could always be added later if a good one appeared.

Okay, no more bikeshedding for me on this issue. I'm covered in paint.

Best,

David

On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
>
>> How about turning it into a function
>>    hstore hstore(hstore, text[])
>> instead?
>
> I just searched through the 2008 spec for a slice/subset operator and came up empty. It seems to define a bunch of predicates for multisets, but not much for arrays.
>
> And looking again at the options, I'm *okay* with %, but not keen on %> anymore (I could see a future where %> and <% it as complement @> and <@ by confirming the presence of keys in an hstore:
>
>    bool = hstore %> text[];
>
> So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?
>
>    hstore = slice(hstore, text[]);
>
> It'd be nice to have one for arrays, too:
>
>    anyarray[] = slice(anyarray[], int[]);
>
> An operator could always be added later if a good one appeared.
>
> Okay, no more bikeshedding for me on this issue. I'm covered in paint.

I don't much like hstore(hstore, text[]) because it's not strictly a
constructor. But I could certainly live with something based on the
word slice. The existing SQL function backing the operator is called
slice_hstore(), whereas I would probably prefer hstore_slice() or just
slice(), but I can't talk about it right now because I have to go
finish laundering the paint out of my entire wardrobe. Having already
written three patches to rename this operator (to three different
names), I'm in no hurry to write a fourth unless the degree of
consensus is sufficient to convince me I shan't need to write a fifth
one.

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

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?

> hstore = slice(hstore, text[]);

+1, particularly seeing that our solution for the other two cases also
comes down to "use the function instead".

regards, tom lane

On Jun 21, 2010, at 10:46 AM, Robert Haas wrote:

> I don't much like hstore(hstore, text[]) because it's not strictly a
> constructor. But I could certainly live with something based on the
> word slice. The existing SQL function backing the operator is called
> slice_hstore(), whereas I would probably prefer hstore_slice() or just
> slice(), but I can't talk about it right now because I have to go
> finish laundering the paint out of my entire wardrobe. Having already
> written three patches to rename this operator (to three different
> names), I'm in no hurry to write a fourth unless the degree of
> consensus is sufficient to convince me I shan't need to write a fifth
> one.

That seems wise. :-)

Best,

David

All,

>> I don't much like hstore(hstore, text[]) because it's not strictly a
>> constructor. But I could certainly live with something based on the
>> word slice. The existing SQL function backing the operator is called
>> slice_hstore(), whereas I would probably prefer hstore_slice() or just
>> slice(), but I can't talk about it right now because I have to go
>> finish laundering the paint out of my entire wardrobe. Having already
>> written three patches to rename this operator (to three different
>> names), I'm in no hurry to write a fourth unless the degree of
>> consensus is sufficient to convince me I shan't need to write a fifth
>> one.

While I would personally prefer to have an operator for the slicing
opeeration, I'm not willing to spend time arguing about it. So, +1 to
implement the subset operation as the function slice(), and defer having
an operator until later.

In some ways, it makes more sense to talk about additional operators in
the context of also adding them to intarray, and I don't want to go
there yet.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> While I would personally prefer to have an operator for the slicing
> opeeration, I'm not willing to spend time arguing about it. So, +1 to
> implement the subset operation as the function slice(), and defer having
> an operator until later.

Yeah, I think the consensus is to avoid picking an operator name at all.
"slice()" is OK by me.

regards, tom lane

On Jun 28, 2010, at 12:10 PM, Tom Lane wrote:

>> While I would personally prefer to have an operator for the slicing
>> opeeration, I'm not willing to spend time arguing about it. So, +1 to
>> implement the subset operation as the function slice(), and defer having
>> an operator until later.
>
> Yeah, I think the consensus is to avoid picking an operator name at all.
> "slice()" is OK by me.

Will this be done for Beta 3?

Best,

David

On Fri, Jul 2, 2010 at 12:36 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 28, 2010, at 12:10 PM, Tom Lane wrote:
>
>>> While I would personally prefer to have an operator for the slicing
>>> opeeration, I'm not willing to spend time arguing about it.  So, +1 to
>>> implement the subset operation as the function slice(), and defer having
>>> an operator until later.
>>
>> Yeah, I think the consensus is to avoid picking an operator name at all.
>> "slice()" is OK by me.
>
> Will this be done for Beta 3?

You forgot to attach the patch. :-)

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

On Jul 2, 2010, at 10:07 AM, Robert Haas wrote:

>>> Yeah, I think the consensus is to avoid picking an operator name at all.
>>> "slice()" is OK by me.
>>
>> Will this be done for Beta 3?
>
> You forgot to attach the patch. :-)

Attached.

Only thing that gave me pause is the presence of the undocumented `slice_array()` function, which is used by the `->` operator. I think I might like to see it renamed `avals(hstore, text[])` if it ever gets documented, as it nicely complements the existing `avals(hstore)` function.

Best,

David

On Fri, Jul 2, 2010 at 2:39 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jul 2, 2010, at 10:07 AM, Robert Haas wrote:
>
>>>> Yeah, I think the consensus is to avoid picking an operator name at all.
>>>> "slice()" is OK by me.
>>>
>>> Will this be done for Beta 3?
>>
>> You forgot to attach the patch.  :-)
>
> Attached.
>
> Only thing that gave me pause is the presence of the undocumented `slice_array()` function, which is used by the `->` operator. I think I might like to see it renamed `avals(hstore, text[])` if it ever gets documented, as it nicely complements the existing `avals(hstore)` function.

Thanks, committed - with the exception that I reverted your change to
the title of section F.13.2, which I believe was in error (and
possibly accidental).

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

On Jul 2, 2010, at 1:38 PM, Robert Haas wrote:

> Thanks, committed - with the exception that I reverted your change to
> the title of section F.13.2, which I believe was in error (and
> possibly accidental).

No, I removed that because that table has only operators, no functions. See http://developer.postgresql.org/docs/postgres/hstore.html.

Best,

David

On Fri, Jul 2, 2010 at 4:43 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jul 2, 2010, at 1:38 PM, Robert Haas wrote:
>
>> Thanks, committed - with the exception that I reverted your change to
>> the title of section F.13.2, which I believe was in error (and
>> possibly accidental).
>
> No, I removed that because that table has only operators, no functions. See http://developer.postgresql.org/docs/postgres/hstore.html.

The section contains two tables. Table F-5 is called "hstore
operators", and table F-6 is called "hstore functions", and those two
tables together make up a section called "F.13.2 hstore operators and
functions".

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

On Jul 2, 2010, at 1:45 PM, Robert Haas wrote:

>> No, I removed that because that table has only operators, no functions. Seehttp://developer.postgresql.org/docs/postgres/hstore.html.
>
> The section contains two tables. Table F-5 is called "hstore
> operators", and table F-6 is called "hstore functions", and those two
> tables together make up a section called "F.13.2 hstore operators and
> functions".

Oh. Duh.

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> You forgot to attach the patch. :-)

> Attached.

Okay, I'm confused. This patch removed an operator named %, which AFAIK
was not controversial. The problematic operator is => no?

regards, tom lane

On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>>> You forgot to attach the patch.  :-)
>
>> Attached.
>
> Okay, I'm confused.  This patch removed an operator named %, which AFAIK
> was not controversial.  The problematic operator is => no?

It used to be =>

After much bikeshedding, we renamed it to %

After more bikeshedding, we decided to remove it altogether, hence the
present patch.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Okay, I'm confused. This patch removed an operator named %, which AFAIK
>> was not controversial. The problematic operator is => no?

> It used to be =>

Nevermind, I *am* confused. Obviously time to knock off for the day;
my brain's fried.

regards, tom lane

On Fri, Jul 2, 2010 at 5:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Okay, I'm confused.  This patch removed an operator named %, which AFAIK
>>> was not controversial.  The problematic operator is => no?
>
>> It used to be =>
>
> Nevermind, I *am* confused.  Obviously time to knock off for the day;
> my brain's fried.

Just as long as you don't ask to have it changed again. :-)

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