Re: JSON for PG 9.2 - Mailing list pgsql-hackers

On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler <david@kineticode.com> wrote:
> Love having the start here. I forwarded this message to Claes Jakobsson, creator of the jansson-using pg-json
extension.He’s a bit less supportive. He gave me permission to quote him here: 
>
>> Frankly I see the inclusion of a JSON datatype in core as unnecessary. Stuff should be moved out of core rather than
in,as we do in Perl. Also, does this patch mean that the 'json' type is forever claimed and can't be replaced by
extensions?
>>
>> There's little reason to reimplement JSON parsing, comparision and other routines when there's a multitude of
alreadygood libraries. 

That's fair enough, but we've had *many* requests for this
functionality in core, I don't see what we lose by having at least
some basic functionality built in.  There is always room for people to
provide extensions and add-ons that build on whatever core support we
provide.  There must be an order of magnitude more demand for this
data type than there is for any other potential new in-core data type.Off the top of my head, I can't think of anything
elsethat's even in 
the same league; can you?

As for whether to use somebody else's implementation or roll our own,
I'm not convinced there's any value in reusing somebody else's
implementation.  Consider a library like json-c, just the first thing
I happened to download.  The license is compatible, so that's good.
But the coding style is completely different from ours, the memory
management is not compatible with ours (it uses calloc and it's not
pluggable), the error messages don't follow our style guidelines and
won't work with our translation infrastructure, it has its own
printfbuf which is redundant with our StringInfoData, it has its own
hash table implementation which is also redundant with code we already
have, and of course it won't contain anything like
CHECK_FOR_INTERRUPTS() any place that might be needed.   Now, sure,
all of those problems are fixable.  But by the time you get done it's
not any less work than writing your own, and probably not as well
adapted to our particular needs.

The jansson library has a pluggable memory allocator, but most of the
other complaints above still apply; and I see, for example, that it
contains its own UTF-8 validator and locale conversion routines, which
is undoubtedly not what we want.  jansson also interprets numeric
values as either a native integer or floating point values, which
limits the amount of precision available and means that values may be
output in a manner quite different from how they were put in.
Although this is probably legal, since RFC4627 states that JSON
parsers may set limits on the range of numbers, I think it's an
unnecessary and undesirable limitation.  I have always enjoyed the
ability to -- for example -- SELECT 400! in PostgreSQL and get an
exact answer, and I think it would be nice if I could store the result
in a JSON object.  I am also quite certain that someone will propose
(or, perhaps, actually write) a function to convert a record to a JSON
object, and I think it would be mighty nice if numeric, int4, and int8
could be transformed into JSON numbers rather than JSON strings, which
isn't going to work - at least for numeric - if there are significant
range or precision limitations.

For XML, it makes a lot of sense for us to integrate with an external
library.  Consider libxml2, the library we actually do integrate with.The root directory has over 275,000 lines of code
in.c and .h files.Obviously, it's worth suffering through some pain (and we definitely 
have suffered through some pain) to avoid having to rewrite some
substantial portion of that code.  Providing some basic JSON support
figures to require about two orders of magnitude less code, which IMHO
makes the calculation completely different.  The reason there are so
many JSON libraries out there is because it only takes a day to write
one.  If you look at a couple of JSON parsers written by other people
and don't find exactly what you're looking for, you just go write one
of your own.  You then have the option to hang out a shingle and
critique the next three people who come along and do the same thing,
but is that really justified?  Odds are good that their reasons for
rolling their own were just as good as yours.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company