hstore ==> and deprecate =>
in [PgSql]
|
From: Josh Berkus on 17 Jun 2010 16:50 On 6/17/10 1:40 PM, Robert Haas wrote: > On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 17 Jun 2010 17:03 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 17 Jun 2010 18:25 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 17 Jun 2010 23:04 Tom Lane wrote: > Josh Berkus <josh(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 18 Jun 2010 13:03
>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |