Re: hstore ==> and deprecate =>

On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler <david(at)kineticode(dot)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(at)tao11(dot)riddles(dot)org(dot)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