On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan <pg@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
