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
