On Thu, Dec 31, 2009 at 11:12 AM, Andrew Dunstan <andrew(at)dunslane(dot)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
Does anyone have any real-world experience with any of the JSON C libraries?
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2009-12-31 21:29:48|
|Subject: Re: Thoughts on statistics for continuously advancing
|Previous:||From: Robert Haas||Date: 2009-12-31 21:19:11|
|Subject: Re: Red-black tree for GIN|