On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler <da...@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 >> <and...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
