Re: hstore ==> and deprecate =>

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-28 18:47:36
Message-ID: 4C28EE48.9060607@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

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

While I would personally prefer to have an operator for the slicing
opeeration, I'm not willing to spend time arguing about it. So, +1 to
implement the subset operation as the function slice(), and defer having
an operator until later.

In some ways, it makes more sense to talk about additional operators in
the context of also adding them to intarray, and I don't want to go
there yet.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-06-28 18:48:36 Re: Keepalives win32
Previous Message Tom Lane 2010-06-28 18:45:05 Re: Keepalives win32