hstore ==> and deprecate =>
in [PgSql]
|
From: Robert Haas on 15 Jun 2010 18:13 On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth <andrew(a)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 -- 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 15 Jun 2010 21:04 On Jun 15, 2010, at 3:13 PM, Robert Haas wrote: > On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth > <andrew(a)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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 Jun 2010 21:58 On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler <david(a)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(a)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 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 -- 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 15 Jun 2010 22:55 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 16 Jun 2010 19:24
On Tue, Jun 15, 2010 at 10:55 PM, David E. Wheeler <david(a)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 |