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.
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.
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".
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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com