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

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.

merlin