Re: hstore ==> and deprecate =>

On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote:

>> It's reasonable to say that the first two are bad design, but I'm
>> a bit less willing to say that the last one is.  What shall we
>> do with that?
>
> Hm, the last one seems to be more akin to
>        hstore - text        yields hstore (key removed)
>        hstore - text[]      yields hstore (keys in array removed)
>        hstore - hstore      yields hstore (keys in hstore removed)

Well, no, the keys aren't removed: you get back an hstore with only those keys (the lhs is unchanged).

> since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore.
>
> Inspired by the already existing
>        hstore ?& text[]     yields boolean (true if set of keys subset of array)
> I suggest
>        hstore & text[]
> as a replacement.

Yes, agreed.

That just leaves
text[] => text[]    yields hstore (with N elements)

Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
       hstore(text[], text[])

Best,

David