hstore ==> and deprecate =>
in [PgSql]
|
From: "David E. Wheeler" on 18 Jun 2010 13:26 On Jun 18, 2010, at 10:03 AM, Josh Berkus wrote: >> I'd vote for %>, out of those. Reason: the operator isn't commutative, >> in fact left and right inputs aren't even the same datatype, so a glyph >> that looks asymmetric seems more natural. > > +1 on %> +1 from me, too. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 28 Jun 2010 14:47
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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |