On 02/05/2014 03:15 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus <j...@agliodbs.com> wrote:
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.
That's a legitimate point of concern. But in and of itself I'm sure
sure it warrants exposing a separate API.
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.
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.
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".
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? With the possible
limited exception of andrew's yet to be delivered enhanced
deserialization routines, I can't think of any. If presented with
reasonable evidence I'll shut my yap, pronto.
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.
I don't. To be pedantic: hstore is in core, but packaged as an
extension. That's a very important distinction.
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. Having things extension packaged
greatly eases concerns about future API changes because if problems
emerge it's not impossible to imagine compatibility extensions to
appear to bridge the gap if certain critical functions change. That's
exactly the sort of thing that we may want to happen here, I think.
The time for this discussion was months ago. I would not have spent many
many hours of my time if I thought it was going to be thrown away. I
find this attitude puzzling, to say the least. You were a major part of
the discussion when we said "OK, we'll leave json as it is (text based)
and add jsonb." That's exactly what we're doing.
And no, hstore is NOT in core. In core for a type means to me it's
builtin, with a fixed Oid.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
