Re: additional json functionality

On Mon, Nov 18, 2013 at 12:10 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> 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.

Hm, but it would matter wouldn't it...the jsonb representation would
give output with the record fields reordered, deduplicated, etc.
Also, presumably, the jsonb serialization would be necessarily slower
for exactly that reason, although perhaps not enough to matter much.

> 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 ...

You'd need explicit jsonb creating functions: record_to_jsonb,
array_to_jsonb etc. AFAIK, these functions would be the only ones
that would have to explicitly reference the jsonb type if you don't
count casts.

It's tempting to *not* make those functions as that would only require
the user to specify jsonb for table columns...you'd then go from json
to jsonb with a cast, perhaps even an implicit one. The disadvantage
there is that you'd then get unsimplified json always.

Hm -- on that note, is it technically feasible to *not* duplicate the
json API implementations, but just (ab)use implicit casting between
the APIs? That way the text API would own all the serialization
routines as it does now but you'd run mutation and searching through
jsonb...

merlin