Merlin,
> Not following this. I do not see how the presence of jsonb helps at
> all. Client to server communication will be text->binary (and vice
> versa) and handling within the server itself will be in binary. This
> is the crux of my point.
Except that handling it on the server, in binary, would require using
the HSTORE syntax. Otherwise you're converting from text JSON and back
whenever you want to nest functions.
> I kind of get this point. But in lieu of a practical use case today,
> what's the rush to implement? I fully anticipate I'm out on left
> field on this one (I have a cot and mini fridge there). The question
> on the table is: what use cases (performance included) does jsonb
> solve that is not solve can't be solved without it?
Indexed element extraction. JSON path queries. JSON manipulation.
If JSONB is in 9.4, then these are things we can build as extensions and
have available long before September 2015 -- in fact, we've already
started on a couple. If JSONB isn't in core as a data type, then we
have to wait for the 9.5 dev cycle to do anything.
> In fact, I'll go further and say it seem wise for all SQL standard
> type work to happen in extensions. As long as it's an in core contrib
> extension, I see no stigma to that whatsoever. It's not clear at all
> to me why the json type was put to the public schema and now we're
> about to double down with jsonb.
I'll agree that having hstore in contrib and json in core has been a
significant source of issues.
On 02/05/2014 12:45 PM, Merlin Moncure wrote:> certainly. I'll shut my
yap; I understand your puzzlement. At the
> time though, I had assumed the API was going to incorporate more of
> the hstore feature set than it did.
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com