Thread: 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
Attachment
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 > > # is currently used for bitwise xor/geo > > merlin > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
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 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 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 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 > regards, tom lane >
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 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
>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes: Robert> I don't think so, either. The most someone might want to doRobert> is make ==> work wherever => does now, but Iwouldn't want toRobert> start monkeying with that without some input from AndrewRobert> Gierth; and I don't think it's astop-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)
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
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote: > 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. +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@kineticode.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@kineticode.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@kineticode.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 sameidea: move from this to that. Anyway, for comparison's purpose: 'foo' ==> 'bar' 'foo' >> 'bar' Pity about :>. Best, David
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> While I don't like the inconsistency between ==> or whatever and>> the use of => in type input and output, I regard thetext>> representation as being much harder to change safely, since client>> code will be parsing it. In this case theinconsistency seems like>> a much smaller problem than changing the text representation. Tom> Perhaps it would be sane to make hstore_in accept either => orTom> ==>, 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@kineticode.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@gmx.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@gmx.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@gmx.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@gmx.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@kineticode.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@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.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@postgresql.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.14159@gmail.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@sss.pgh.pa.us> wrote:
> Joseph Adams <joeyadams3.14159@gmail.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@gmx.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@gmx.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@kineticode.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@kineticode.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@momjian.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@kineticode.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@sss.pgh.pa.us> wrote: > "David E. Wheeler" <david@kineticode.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
Attachment
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> But actually, there's another issue here: hstore defines not oneTom> 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, butTom> I'm a bit less willing to say that the last one is. What shallTom> 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@tao11.riddles.org.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@tao11.riddles.org.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 muchbetter 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@kineticode.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@tao11.riddles.org.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 muchbetter 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@kineticode.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
Attachment
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. +> looksmore like an arrow (sort of). But it doesn't much matter, as long as it works. Best, David
Robert Haas <robertmhaas@gmail.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@kineticode.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 correlatesin 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 returnsan 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@agliodbs.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@agliodbs.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@agliodbs.com> wrote: > On 6/17/10 1:40 PM, Robert Haas wrote: >> On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh@agliodbs.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@agliodbs.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@agliodbs.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@dunslane.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@kineticode.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, doesthe spec say anything about array operators? Best, David
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler <david@kineticode.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, doesthe 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 predicatesfor 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 <% itas 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@kineticode.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 predicatesfor 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 <% itas 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@kineticode.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@agliodbs.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@kineticode.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 complementsthe existing `avals(hstore)` function. Best, David
Attachment
On Fri, Jul 2, 2010 at 2:39 PM, David E. Wheeler <david@kineticode.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 complementsthe 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@kineticode.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@kineticode.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@sss.pgh.pa.us> wrote: > "David E. Wheeler" <david@kineticode.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@gmail.com> writes:
> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl@sss.pgh.pa.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