Re: hstore ==> and deprecate =>

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Michael Glaesemann <grzm(at)seespotcode(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: hstore ==> and deprecate =>
Date: 2010-06-16 01:04:07
Message-ID: F0E4A6F0-4DDC-4FE7-8468-9D86F74D1B4C@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:

> On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
> <andrew(at)tao11(dot)riddles(dot)org(dot)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 much better parallel, it being that it returns the keys in the rhs array. So I think something closer to it would be better. Some suggestions:

~>
<-
#>
+>

Ooh, I like +>, as being: give me more than -> does.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-16 01:58:23 Re: hstore ==> and deprecate =>
Previous Message Josh Berkus 2010-06-16 00:32:08 Re: Proposal for 9.1: WAL streaming from WAL buffers