Re: jsonb and nested hstore - Mailing list pgsql-hackers

On Thu, Feb 27, 2014 at 11:11 AM, Josh Berkus <josh@agliodbs.com> wrote:
> Because the course Andrew is following is the one which *this list*
> decided on in CF3, no matter that people who participated in that
> discussion seem to have collective amnesia.  There was a considerable
> amount of effort involved in implementing things this way, so if Hackers
> suddenly want to retroactively change a collective decision, I think
> they should be prepared to pitch in and help implement the changed plan.

I think you've completely misunderstood my remarks. For the most part
I agree that there are advantages to having hstore and jsonb share the
same tree representation, and this may be where Robert and I differ.
My concern is: Having gone to that considerable amount of effort, why
on earth does jsonb not get the benefit of the hstore stuff
immediately, since it's virtually the same thing? What is it that
we're actually being asked to wait for?

Let me be more concrete about what my concern is right now:

postgres=# select '{"foo":{"bar":"yellow"}}'::jsonb || '{}'::jsonb;        ?column?
--------------------------"foo"=>{"bar"=>"yellow"}
(1 row)

I put in jsonb, but got out hstore, for this totally innocent use of
the concatenation operator. Now, maybe the answer here is that we
require people to cast for this kind of thing while using jsonb. The
problems I see with that are:

1. It's pretty ugly, in a way that people that care about jsonb are
particularly unlikely to find acceptable. When you mix in GIN/GiST
compatibility to the mix, it gets uglier.

2. Don't we already have a much simpler way of casting from hstore to json?

> One of the issues there is that, due to how we handle types, a type
> which has been available as an extension can never ever become a core
> type because it breaks upgrading, per the discussion about hstore2.  For
> better or for worse, we chose to make json-text a core type when it was
> introduced (and XML before it, although that was before CREATE
> EXTENSION).  This means that, if we have jsonb as an extension, we'll
> eventually be in the position where the recommended json type with all
> the features is an extension, whereas the legacy json type is in core.

I take issue with characterizing the original json type as legacy
(it's json, not anything else - jsonb isn't quite json, much like
BSON), but leaving that aside: So? I mean, really: what are the
practical consequences of packing everything as an extension? I can
see some benefits to doing it, but like Robert I have a harder time
seeing a cost.

To be clear: I would really like for jsonb to have parity with hstore.
I don't understand how you can argue for it being unfortunate that the
original json may occupy a privileged position as a core type over
jsonb on the one hand, while not also taking issue with jsonb clearly
playing second fiddle to hstore. Wasn't the whole point of their
sharing a binary representation that that didn't have to happen?

-- 
Peter Geoghegan