Robert Haas <robertmhaas@gmail.com> writes:
> 2010/12/14 Andrew Dunstan <andrew@dunslane.net>:
>> On 12/14/2010 12:06 PM, Robert Haas wrote:
>>> Not exactly, because in hstore all the element values have to be,
>>> specifically, text. �Having hstores of other kinds of objects would,
>>> presumably, be useful.
>> I love hstore, and I've used it a lot, but I don't think there's much future
>> in doing this. This is part of what JSON would buy us, isn't it?
> Well, JSON would give you numbers and booleans, but that's a pretty
> small subset of all the types in the universe.
Sure, but once you have those three, the set of remaining use-cases for
a generalized hstore has dropped from epsilon to epsilon cubed. I don't
think there's much space left there for a useful type that doesn't make
the full jump to "record" (ie, allowing each value to be any SQL type).
Also, the more cases you support, the harder it is to write code that
processes the type, as we already saw in the other thread about
record-access functions. It's not unlikely that something more flexible
than JSON would be less useful not more so, because of the ensuing usage
complexity. (This is part of why hstore seems to be occupying a sweet
spot --- it may not cover everything you want to do, but "it's all text"
does simplify usage.)
regards, tom lane
