From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Glaesemann <grzm(at)seespotcode(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: hstore ==> and deprecate => |
Date: | 2010-06-12 16:29:11 |
Message-ID: | A29B9862-F571-4799-9245-098812EBF3DF@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-12 16:54:55 | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Previous Message | David E. Wheeler | 2010-06-12 16:23:44 | Re: hstore ==> and deprecate => |