Re: jsonb and nested hstore

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> 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.

I was taking a slightly different perspective on it, though the devil is
almost certainly in the details. I'll be the first to admit that I've
not looked in detail at the patch either and so I've been trying to
avoid commenting on implementation specifics, but I was seeing this from
the perspective that we are building a single hierarchical typed data
store and then providing two interfaces to it. The way we're getting
there is a little awkward, in hindsight, and we'd like to have backwards
compatibility for one of the interfaces (and its on-disk storage), but
I'm not entirely sure that we'd actually end up in a different place
when we reach the end of this road.

Had we implemented jsonb first and then added hstore to it, would much
be different from the result we're getting here beyond the names of the
functions and the backwards-compatibility for the older on-disk format?
Are we really paying a high cost to support that older format?

The specific issues mentioned on this thread look more like bugs to be
addressed or additional operators which need to be implemented for
jsonb (imv, that should really be done for 9.4, but we have this
deadline looming...) along with perhaps dropping the implicit cast
between json and hstore (is there really a need for it..?).

Thanks,

Stephen