On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler <da...@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 already good 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 else that'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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
