* Robert Haas (robertmh...@gmail.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
signature.asc
Description: Digital signature