Re: jsonb and nested hstore

On Thu, Feb 27, 2014 at 5:54 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> And it's not just that "broadly speaking most people would prefer
> the interface to speak JSON"; it's that a JSONish interface for indexed
> heirachical data is a Big Feature which will drive adoption among web
> developers, and hstore2 without JSON support simply is not. At trade
> shows and developer conferences, I get more questions about PostgreSQL's
> JSON support than I do for any new feature since streaming replication.

I work for Heroku; believe me, I get it. I'd go along with abandoning
nested hstore as a user-visible thing if I thought it bought jsonb
something and I thought we could, but I have doubts about that.

I understand why the nested hstore approach was taken. It isn't that
desirable to maintain something like a jsonb in parallel, while also
having the old key/value, untyped hstore. They are still fairly
similar as these things go. Robert said something about re-using op
classes rather than waiting for new op classes to be developed, but
why do we need to wait? These ones look like they work fine - what
will be better about the ones we develop later that justifies their
independent existence? Why should we believe that they won't just be
copied and pasted? The major problem is that conceptually, hstore
"owns" them (which is at least in part due to old hstore code rather
than nested hstore code), and so we need a better way to make that
work. We need some commonality and variability analysis, because
duplicating large amounts of hstore isn't very appealing.

> As far as I can tell, moving jsonb to contrib basically requires
> rewriting a bunch of code, without actually fixing any of the bugs which
> have been discussed in the more technical reviews. I'm really unclear
> what, at this point, moving jsonb to /contrib would improve.

These are all of the additions to core, excluding regression tests and docs:

***SNIP***
src/backend/catalog/system_views.sql | 8 +
src/backend/utils/adt/Makefile | 2 +-
src/backend/utils/adt/json.c | 44 ++--
src/backend/utils/adt/jsonb.c | 455 ++++++++++++++++++++++++++++++++
src/backend/utils/adt/jsonb_support.c | 1268
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/backend/utils/adt/jsonfuncs.c | 1159
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
src/include/catalog/pg_cast.h | 4 +
src/include/catalog/pg_operator.h | 12 +
src/include/catalog/pg_proc.h | 44 +++-
src/include/catalog/pg_type.h | 6 +
src/include/funcapi.h | 9 +
src/include/utils/json.h | 15 ++
src/include/utils/jsonapi.h | 8 +-
src/include/utils/jsonb.h | 245 +++++++++++++++++
**SNIP**

It's not immediately obvious to me why moving that into contrib
requires much work at all (relatively speaking), especially since
that's where much of it came from to begin with, although I grant that
I don't grok the patch.

Here is the line of reasoning that suggests to me that putting jsonb
in contrib is useful:

* It is not desirable to maintain some amount of common code between
hstore (as it exists today) and jsonb. This is of course a question of
degree (not an absolute), so feel free to call me out on the details
here, but I'm of the distinct impression that jsonb doesn't have that
much of an independent existence from hstore - what you could loosely
call "the jsonb parts" includes in no small part historic hstore code,
and not just new nested hstore code (that could reasonably be broken
out if we decided to jettison nested hstore as a user-visible thing
and concentrated on jsonb alone, as you would have us do). In other
words, Oleg and Teodor built nested hstore on hstore because of
practical considerations, and not just because they were attached to
hstore's perl-like syntax. They didn't start from scratch because that
was harder, or didn't make sense.

* We can't throw hstore users under the bus. It has to stay in contrib
for various reasons.

* It hardly makes any sense to have an in-core jsonb if it comes with
no batteries included. You need to install hstore for this jsonb
implementation to be of *any* use anyway. When you don't have the
extension installed, expect some really confusing error messages when
you go to create a GIN index. jsonb is no use on its own; why not just
make it all or nothing?

Another way of resolving this tension might be to push a lot more of
hstore into core than is presently proposed, but that seems like a
more difficult solution with little to no upside.
--
Peter Geoghegan