On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers