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

On 02/05/2014 03:15 PM, Merlin Moncure wrote:
> On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 02/05/2014 07:48 AM, Merlin Moncure wrote:
>>> Another point I'm struggling with is
>>> what jsonb brings to the table that isn't covered either hstore or
>>> json; working through a couple of cases I find myself not using the
>>> jsonb functionality except as a 'hstore json formatter' which the json
>>> type covers.  I'm probably being obtuse, but we have to be cautious
>>> before plonking a couple of dozen extra functions in the public
>>> schema.
>> There's three reasons why it's worthwhile:
>>
>> 1) user-friendliness: telling users they need to do "::JSON" and
>> "::HSTORE2" all the time is sufficiently annoying -- and prone to
>> causing errors -- to be a blocker to adoption by a certain, very
>> numerous, class of user.
> That's a legitimate point of concern.  But in and of itself I'm sure
> sure it warrants exposing a separate API.
>
>> 2) performance: to the extent that we can operate entirely in JSONB and
>> not transform back and forth to JSON and HSTORE, function calls (and
>> index lookups) will be much faster.  And given the competition, speed is
>> important.
> Not following this.  I do not see how the presence of jsonb helps at
> all. Client to server communication will be text->binary (and vice
> versa) and handling within the server itself will be in binary.  This
> is the crux of my point.
>
>> 3) growth: 9.4's JSONB functions are a prerequisite to developing richer
>> JSON querying capabilities in 9.5 and later, which will go beyond "JSON
>> formatting for HSTORE".
> I kind of get this point.   But in lieu of a practical use case today,
> what's the rush to implement?   I fully anticipate I'm out on left
> field on this one (I have a cot and mini fridge there).  The question
> on the table is: what use cases (performance included) does jsonb
> solve that is not solve can't be solved without it?  With the possible
> limited exception of andrew's yet to be delivered enhanced
> deserialization routines, I can't think of any.  If presented with
> reasonable evidence I'll shut my yap, pronto.
>
>> Frankly, if it were entirely up to me HSTORE2 would be part of core and
>> its only interface would be JSONB.  But it's not.  So this is a compromise.
> I don't.  To be pedantic: hstore is in core, but packaged as an
> extension.  That's a very important distinction.
>
> In fact, I'll go further and say it seem wise for all SQL standard
> type work to happen in extensions.  As long as it's an in core contrib
> extension, I see no stigma to that whatsoever.  It's not clear at all
> to me why the json type was put to the public schema and now we're
> about to double down with jsonb.  Having things extension packaged
> greatly eases concerns about future API changes because if problems
> emerge it's not impossible to imagine compatibility extensions to
> appear to bridge the gap if certain critical functions change.  That's
> exactly the sort of thing that we may want to happen here, I think.
>


The time for this discussion was months ago. I would not have spent many 
many hours of my time if I thought it was going to be thrown away. I 
find this attitude puzzling, to say the least. You were a major part of 
the discussion when we said "OK, we'll leave json as it is (text based) 
and add jsonb." That's exactly what we're doing.

And no, hstore is NOT in core. In core for a type means to me it's 
builtin, with a fixed Oid.

cheers

andrew