On Thu, Dec 31, 2009 at 11:12 AM, Andrew Dunstan <and...@dunslane.net> wrote: > David E. Wheeler wrote: >> On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote: >>> >>> I think the primary use will be to load a JSON value into Perl or Python >>> and process it there. So a json type that doesn't have any interesting >>> operators doesn't sound useless to me. The features I would like to get >>> out of it are input validation and encoding handling and smooth >>> integration with said languages. >>> >> >> What about access to various parts of a JSON data structure? Or is that >> just asking for too much trouble up-front? > > IMNSHO it's essential. I think Peter's approach of ignoring this requirement > is extremely shortsighted.
I could go either way on this. As a practical matter, we probably shouldn't pick a library that is only a validator without any ability to manipulate the data structure. And as a further practical matter, that done, it's probably not that much work to expose whatever other functionality that library provides. But I would not go to the extent of saying that we should try to figure out from first principles what functionality we want to include and then make it a requirement that the chosen library must support all of those things. That seems like a recipe for failure... Anyhow, that brings me back to the question I asked upthread, which is "Can/should we suck one of these libraries into our code base (and if so, which?) or do we need to add an analogue of --with-libxml so that we can link against an external library if present and omit the feature otherwise?". Does anyone have any real-world experience with any of the JSON C libraries? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers