On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan <p...@heroku.com> wrote: > In order to make a rational decision to do the work incrementally, we > need to know what we're putting off until 9.5. AFAICT, we have these > operator classes that work fine with jsonb for the purposes of > hstore-style indexing (the hstore operator classes). Wasn't that the > point? When there is a dedicated set of jsonb operator classes, what > will be different about them, other than the fact that they won't be > hstore operator classes? A decision predicated on waiting for those to > come in 9.5 must consider what we're actually waiting for, and right > now that seems very hazy.
I really would like an answer to this question. Even if I totally agreed with Andrew's assessment of the relative importance of having jsonb be an in-core type, versus having some more advanced indexing capabilities right away, this is still a very salient question. I appreciate that the "put jsonb in hstore extension to get indexing right away" trade-off is counter-intuitive, and it may even be that there is an "everybody wins" third way that sees us factor out code that is common to both jsonb and hstore as it exists today (although I'm not optimistic about that). I would like to emphasize that if you want to defer working on hstore-style jsonb operator classes for one release, I don't necessarily have a problem with that. But, I must insist on an answer here, from either you or Oleg or Teodor (it isn't apparent that Oleg and Teodor concur with you on what's important): what did we run out of time for? What will be different about the jsonb operator classes that you're asking us to wait for in a future release? I understand that there are ambitious plans for a VODKA-am that will support indexing operations on nested structures that are a lot more advanced than those enabled by the hstore operator classes included in these patches. However, surely these hstore operator classes have independent value, or represent incremental progress? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
