>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> But actually, there's another issue here: hstore defines not oneTom> 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, butTom> I'm a bit less willing to say that the last one
is. What shallTom> 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)
