Re: hstore ==> and deprecate => - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: hstore ==> and deprecate =>
Date
Msg-id A29B9862-F571-4799-9245-098812EBF3DF@kineticode.com
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  (Florian Pflug <fgp@phlo.org>)
Responses Re: hstore ==> and deprecate =>  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: hstore ==> and deprecate =>
Next
From: Tom Lane
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages