>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> But actually, there's another issue here: hstore defines not one Tom> but three => operators: Tom> text => text yields hstore (with 1 element) Tom> text[] => text[] yields hstore (with N elements) Tom> hstore => text[] yields hstore (subset) Tom> It's reasonable to say that the first two are bad design, but Tom> I'm a bit less willing to say that the last one is. What shall Tom> we do with that? I added the second two primarily by analogy with the first; following the existing pattern seemed to be the way to go at the time. If the first (text => text) operator hadn't already been present when I started looking at it, I'd probably have stuck to hstore() for all construction methods rather than defining an operator. Creating operators that take only existing builtin types is obviously a namespace problem in that multiple independent modules might get into trouble by choosing the same operators. Perhaps this should be formalized as some sort of style guideline for module authors? I'm happy with deprecating the first two => in favour of hstore() if that is in line with general opinion. The hstore => text[] slice could be replaced by another operator name; the existing name comes from the analogy that (hstore -> text[]) returns the list of values, whereas (hstore => text[]) returns both the keys and values. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
