On Wed, Feb 26, 2014 at 7:42 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> The jsonb set will get larger as time goes on. I don't think either of you
> are thinking very clearly about how we would do this. Extensions can't call
> each other's code. So the whole notion we have here of sharing the tree-ish
> data representation and a lot of the C API would go out the window, unless
> you want to shoehorn jsonb into hstore. Frankly, we'll look silly with json
> as a core type and the more capable jsonb not.
When are you going to add more jsonb functions? ISTM that you have a
bunch of new ones right here (i.e. the hstore functions and
operators). Why not add those ones right now?
I don't understand why you'd consider it to be a matter of shoehorning
jsonb into hstore (and yes, that is what I was suggesting). jsonb is a
type with an implict cast to hstore, that is binary coercible both
ways. Oleg and Teodor had at one point considered having the ouput
format controlled entirely by a GUC, so there'd be no new jsonb type
at all. While I'm not asserting that you should definitely not
structure things this way (i.e. have substantial in-core changes), it
isn't obvious to me why this can't work as an extension, especially if
doing everything as part of an extension helps the implementation.
Please point out anything that I may have missed.
Speaking from a Heroku perspective, I know the company places a huge
value on jsonb. However, I believe it matters not a whit to adoption
whether or not it's an extension, except insofar as having it be an
extension helps the implementation effort (that is, that it helps
there be something to adopt), or hinders that effort.
--
Peter Geoghegan
