Re: PATCH: Add hstore_to_json()
От | Robert Haas |
---|---|
Тема | Re: PATCH: Add hstore_to_json() |
Дата | |
Msg-id | 603c8f070912181613h6383378fl3490bf8de65e342a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: Add hstore_to_json() (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan <andrew@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
В списке pgsql-hackers по дате отправления: