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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
