Re: hstore ==> and deprecate =>

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

In response to

Responses

Browse pgsql-hackers by date

  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 =>