On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan <and...@dunslane.net> wrote: >> One problem is that there is not a single well-defined mapping between >> these types. I would say generally that XML and YAML both have more >> types of constructs than JSON. The obvious ways of translating an >> arbitrary XML document to JSON are likely not to be what people want >> in particular cases. > Right. XML semantics are richer, as I pointed out when we were discussing > the various EXPLAIN formats.
You say "richer"; I say "harder to map onto data structures". But we can agree to disagree on this one... I'm sure there are good tools out there. :-) >> I think the performance argument is compelling, too, but we can't even >> try benchmarking it unless we can define what we're even talking >> about. > > Yes, there is indeed reason to think that JSON processing, especially > parsing, will be more efficient, and I suspect we can provide ways of > accessing the data that are lots faster than XPath. JSON is designed to be > lightweight, XML is not. > > Mind you, the XML processing is not too bad - I have been working much of > the last few months on a large custom billing system which produces XML > output to create paper/online invoices from, and the XML construction is one > of the fastest parts of the whole system. That doesn't surprise me very much. If there's a problem with operations on XML, I think it tends to be more on the parsing side than the generation side. But even there I agree it's not terrible. The main reason I like JSON is for the simpler semantics - there's exactly one way to serialize and deserialize a data structure, and everyone agrees on what it is so the error cases are all handled by the parser itself, rather than left to the application programmer. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers