On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler <david@kineticode.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
predicatesfor 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 <%
itas 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