Re: jsonb and nested hstore - Mailing list pgsql-hackers

On Thu, Feb 27, 2014 at 1:11 PM, Josh Berkus <josh@agliodbs.com> wrote:
> However, we had this discussion already in November-December, which
> resulted in the current patch.  Now you and Robert want to change the
> rules on Andrew, which means Andrew is ready to quit, and we go another
> year without JSON indexing.

How we got here is not the point.  All that matters is what's going to
happen from here.  Here are the facts as I see them:

1) we've worked ourselves into a situation where we're simultaneously
developing two APIs that do essentially exactly the same thing (hstore
and jsonb).   Text json is not the problem and is irrelevant to the
discussion.

2) The decision to do that was made a long time ago.  I complained
loudly as my mousy no-programming-only-griping voice would allow here:
http://postgresql.1045698.n5.nabble.com/JSON-Function-Bike-Shedding-tp5744932p5746152.html.The decision was made (and
Robertcast one of the deciding votes in
 
support of that decision) to bifurcate hstore/json.  I firmly believe
that was a mistake but there's no point in revisiting it. Done is
done.

3) In it's current state jsonb is not very useful and we have to
recognize that; it optimizes text json but OTOH covers, maybe 30-40%
of what hstore offers.  In particular, it's missing manipulation and
GIST/GIN.  The stuff it does offer however is how Andrew, Josh and
others perceive the API will be used and I defer to them with the
special exception of deserialization (the mirror of to_json) which is
currently broken or near-useless in all three types.  Andrew
recognized that and has suggested a fix; even then to me it only
matters to the extent that the API is clean and forward compatible.

Here are the options on the table:
a) Push everything to 9.5 and introduce out of core hstore2/jsonb
extensions to meet market demand.  Speaking practically, 'out of core'
translates to "Can't be used" to most industrial IT shops.  I hate
this option but recognize it's the only choice if the code isn't ready
in time.

b) Accept hstore2 but push jsonb on the premise they should be married
in some way or that jsonb simply isn't ready.  I'm not a fan of this
option either unless Andrew specifically thinks it's a good idea.  The
stuff that is there seems to work pretty well (again, except
deserialization which I haven't tested recently) and the jsonb
patterns that are in place have some precedent in terms of the text
json type.

c) Accept hstore2 and jsonb as in-core extensions (assuming code
worthiness).  Since extensions can't call into each other (this really
ought to be solved at some point) this means a lot of code copy/pasto. The main advantage here is that it reduces the
penaltyof failure
 
and avoids pollution of the public schema.  I did not find the
rationale upthread that there was a stigma to in-core extensions in
any way convincing.  In fact I'd go further and suggest that we really
ought to have a project policy to have all non-SQL standard functions,
operators and types as extensions from here on out.  Each in-core type
introduction after having introduced the extension system has left me
scratching my head.

d) The status quo.  This essentially means we'll have to liberally
document how things are (to avoid confusing our hapless users) and
take Andrew at his word that a separate extension will materialize
making jsonb more broadly useful.  The main concern here is that the
market will vote with their feet and adopt hstore API style broadly,
sticking us with a bunch of marginally used functions in the public
namespace to support forever.

My personal preference is c) but am perfectly ok with d), particularly
if there was more visibility into the long term planning.  Good
documentation will help either way and that's why I signed up for it.

merlin