Re: jsonb and nested hstore

On 03/03/2014 06:17 PM, Peter Geoghegan wrote:
> Good. Hopefully you also mean that you recognize the dilemma referred
> to above - that the hstore code reuse made a certain amount of sense,
> and that more than likely the best way forward is to work out a way to
> make it work. I'm not immediately all that concerned about what the
> least worst way of doing that is (I just favor putting everything in
> hstore on practical grounds).

Well, I don't see how this is "on practical grounds" at this point.
Whether we keep jsonb in core or not, we have an equal amount of work
ahead of us.  That's why I said the single-extension approach was
"conceptually simpler" rather than "actually simpler".  It's easier to
understand, not necessarily easier to implement at this point.

Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to implement based on that collective decision.  So if we're going
to change course, we need a specific reason to change course, not just
"it seems like a better idea now" or "I wasn't paying attention then".

The "one extension to rule them all" approach also has the issue of
Naming Things, but I think that could be solved with a symlink or two.

> Another way to solve this problem might
> be to simply live with the code duplication between core and hstore on

What code duplication?

> the grounds that hstore will eventually be deprecated as people switch
> to jsonb over time (so under that regime nothing new would ever be
> added to hstore, which we'd eventually remove from contrib entirely,
> while putting everything new here in core). I don't favor that
> approach, but it wouldn't be totally unreasonable, based on the
> importance that is attached to jsonb, and based on what I'd estimate
> to be the actual amount of code redundancy that that would create
> (assuming that hstore gets no new functions and operators, since an
> awful lot of the hstore-local code after this patch is applied is new
> to hstore). I wouldn't stand in the way of this approach.

Realistically, hstore will never go away.  I'll bet you a round or two
of pints that, if we get both hstore2 and jsonb, within 2 years the
users of jsonb will be an order of magnitude more numerous that then
users of hstore, but folks out there have apps already built against
hstore1 and they're going to keep on the hstore path.

In the discussion you haven't apparently caught up on yet, we did
discuss moving *hstore* into core to make this whole thing easier.
However, that fell afoul of the fact that we currently have no mechanism
to move types between extensions and core without breaking upgrades for
everyone.  So the only reason hstore is still an extension is because of
backwards-compatibility.

> In my view the most important thing right now is that before anything
> is committed, at the very least there needs to be a strategy around
> getting hstore-style GIN indexing in jsonb. 

I think it's a good idea to have a strategy.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com