On Tue, Feb 25, 2014 at 12:38 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers