Re: hstore ==> and deprecate =>

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, 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-21 17:46:31
Message-ID: AANLkTinY59EH_FEpKP4KWVdElxiiDaUz_RLSoFF8lSxE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
>
>> How about turning it into a function
>>    hstore hstore(hstore, text[])
>> instead?
>
> I just searched through the 2008 spec for a slice/subset operator and came up empty. It seems to define a bunch of predicates for multisets, but not much for arrays.
>
> And looking again at the options, I'm *okay* with %, but not keen on %> anymore (I could see a future where %> and <% it as complement @> and <@ by confirming the presence of keys in an hstore:
>
>    bool = hstore %> text[];
>
> So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?
>
>    hstore = slice(hstore, text[]);
>
> It'd be nice to have one for arrays, too:
>
>    anyarray[] = slice(anyarray[], int[]);
>
> An operator could always be added later if a good one appeared.
>
> Okay, no more bikeshedding for me on this issue. I'm covered in paint.

I don't much like hstore(hstore, text[]) because it's not strictly a
constructor. But I could certainly live with something based on the
word slice. The existing SQL function backing the operator is called
slice_hstore(), whereas I would probably prefer hstore_slice() or just
slice(), but I can't talk about it right now because I have to go
finish laundering the paint out of my entire wardrobe. Having already
written three patches to rename this operator (to three different
names), I'm in no hurry to write a fourth unless the degree of
consensus is sufficient to convince me I shan't need to write a fifth
one.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-21 17:47:33 Re: deprecating =>, take two
Previous Message Dimitri Fontaine 2010-06-21 17:46:17 Re: deprecating =>, take two