Re: hstore ==> and deprecate =>
От | Robert Haas |
---|---|
Тема | Re: hstore ==> and deprecate => |
Дата | |
Msg-id | AANLkTil9Lkf86_6TMJPpLGChojL5Z3XaKySY7835Wd22@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: hstore ==> and deprecate => ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: hstore ==> and deprecate =>
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: