Merlin,
> *) Aside from the text in and out routines, how is 'jsbonb' different
> from the coming 'nested hstore'? Enough to justify two code bases?
In/out functions and defaults are all different. Otherwise, the two
types will be accessing the same code base, so no duplication. Think of
is as XML vs. TEXT.
> Maybe we can cheat a little bit overload the functions so that one the
> existing APIs (hstore or json) can be recovered -- only adding what
> minimal functionality needs to be added to handle the type distinction
> (mostly on serialization routines and casts). What I'm driving at
> here is that it would be nice if the API was not strongly bifurcated:
> this would cause quite a bit of mindspace confusion.
I'll also note that for functions designed for output to the client, it
doesn't make much of a difference whether the result is JSON or JSONB,
since the string representation will be identical. However, it makes a
difference if the data is going to be stored, since a double conversion
on a large JSON value would be expensive.
In other words, we need a version of each function which outputs JSONB,
but that version doesn't have to be the default if users don't specify.
Note that this raises the issue of "first alternate data type ambiguity"
again for overloading builtin functions. We really need that method of
"prefering" a specific version of the function ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
