On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> I don't think any name that doesn't begin with "json" is acceptable. I could
> live with "jsonb". It has the merit of brevity, but maybe it's a tad too
> close to "json" to be the right answer.
I think that seems right. Couple thoughts:
*) Aside from the text in and out routines, how is 'jsbonb' different
from the coming 'nested hstore'? Enough to justify two code bases?
*) How much of the existing json API has to be copied over to the
jsonb type and how exactly is that going to happen? For example, I
figure we'd need a "record_to_jsonb" etc. for sure, but do we also
need a jsonb_each()...can't we overload instead?
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.
merlin