On Mon, Feb 24, 2014 at 12:31 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Aside from that, I want our docs to make a strong endorsement of using
> jsonb over json for most users. jsonb will continue to be developed and
> improved in the future; it is very unlikely that json will. Maybe
> that's what I should say rather than anything about efficiency.
>
> In other words: having an ambiguous, complex evaluation of json vs.
> jsonb does NOT benefit most users. The result will be some users
> choosing json and then pitching fit when they want jsonb in 9.5 and have
> to rewrite all their tables.
>
> Mind you, we'll need to fix the slow deserialization, though.
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.
You really *can't* fix the fact that jsonb takes longer to
(deserialize than json. I mean, it's possible the code can be
optimized. But since json is stored in the exact format in which it
is to be emitted, the output function is basically just memcpy().
You're never going to get that kind of speed out of code that actually
has to do something, and I suspect you're going to find that it's hard
to come close.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
