Re: jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:55 PM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
> On Feb 27, 2014, at 5:31 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> Now, it's confusing that it has to go through hstore, perhaps, but
>> that's hardly all that bad in and of itself.
>
> Yes, it is. It strikes me as irrational to have jsonb depend on hstore. Let's be honest with ourselves: if we were starting over, we wouldn't start by creating our own proprietary hierarchical type and then making the hierarchical type everyone else uses depend on it. hstore exists because json didn't. But json does now, and we shouldn't create a jsonb dependency on hstore.

Right. I think this is one of the smartest things that anyone has
said on this thread. I don't have any objection to the idea of
enhancing hstore to support hierarchical data; I completely understand
the appeal of such a change. Nor do I have any objection to the idea
of a binary-json type in core (or out of core); there are obvious uses
for such a thing.

But what's happened here is not the sum of those two admirable
proposals. hstore has been augmented not only to support hierarchical
data but also with a notion of typed data that matches that of JSON
(except that I think the hstore and jsonb patches may have slightly
different notions as to what constitutes a valid number). The
internal format for jsonb has been contrived to match the
upward-compatible format designed for JSON. And thus jsonb depends on
hstore for the functionality that it isn't able to provide for itself.

Taken individually, none of those decisions seem crazy, but taken
together it's pretty weird. Instead of inventing a new type (jsonb)
designed from the ground up to do what we want, we're, well, we're
doing what Christophe says: creating our own proprietary hierarchical
type and then making the hierarchical type everyone else uses depend
on it. Described in those terms, it's hard for me to believe that
anyone here thinks that's not a strange thing to do.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company