On Thu, Feb 27, 2014 at 1:11 PM, Josh Berkus <j...@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 Robert cast 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 penalty of 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers