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

On Tue, Feb 25, 2014 at 12:38 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 02/25/2014 08:13 AM, Robert Haas wrote:
>> I think you've got your head stuck deeply in the sand.  The json data
>> type works exactly like the xml data type has always worked.  There
>> have been occasional noises about making an xmlb data type, but
>> nobody's minded enough to do anything about it, or at least not in
>> this forum.  So if the json data type has no future and is crap, then
>> the same presumably holds of the xml data type.  But I don't think
>> anyone here believes that, unless they just hate xml on general
>> principle, which I can certainly understand.
>
> Well, if we had an XMLB, I would in fact be making the same argument.
> I'll point out the only reason we're keeping the original json instead
> of forcing an upgrade to jsonb, per earlier discussions, is
> backwards-compatibility.  If we had never had a json-text, and Merlin
> was proposing adding one now alongside jsonb, I'd be arguing against
> doing so.

You can argue that all you like.  But the same argument was made and
rejected at the time we (I) added the original json type.  So I don't
believe that you can claim that your argument is backed by any sort of
consensus, because AFAICS it isn't.

>> In short, I think you're viewing everything about jsonb with
>> rose-colored glasses on, and that your enthusiasm is mostly wishful
>> thinking.  Will there be good things about jsonb?  Of course.  Will
>> lots of people want to use it for those reasons?  Very likely.  Will
>> it be better than json in all ways and for all purposes?  No, and
>> implying the contrary is just plain wrong.
>
> It hurts our adoption substantially to confuse developers.  We need to
> recommend one type over the other, hence "Use jsonb unless you need X".
>  Merlin is pushing the type of multivariable comparison where *I*
> wouldn't be able to make sense of which one I should pick, let alone
> some web developer who's just trying to get a site built.  That sort of
> thing *really* doesn't help our users.

I don't have any objection to editing what Merlin wrote to be clear
and concise; I don't think he meant for it to be considered for
inclusion in the documentation in exactly that form anyway.  I do have
an objection to including your unjustified partisanship in our
documentation as fact.

The reality is that if you have a bunch of JSON documents indexed by
some ID number and expect to usually retrieve the whole document, you
probably don't want jsonb.  You probably want one integer column and
one json column, because it's gonna be faster that way.  And if you
expect to usually retrieve only part of the document, then you are
probably better off using separate columns for the separate parts of
the document, because I bet that extracting a portion of a large
document is still going to require de-TOASTing the whole thing, or at
least all the data preceding the last byte offset of interest, which
is full of lose.  The situation where jsonb is going to win is where
either (1) you or your client are so stuck in the document database
model that you can't fathom the idea that using a real database schema
might improve performance or (2) you have so many different things
(pseudocolumns, as it were) that you might want to extract from any
given JSON blob that it's impractical to use real columns for all of
those.  I agree those are both real use cases.  I do not agree that
they are the only or most common use cases.  And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real column definitions.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company