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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
