On Tue, Jun 16, 2009 at 12:04 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Greg Stark <gsst...@mit.edu> writes: >> I'm picturing adding a new tag, such as <iostats>, or actually I was >> thinking of <dtrace>. If we have separate tags for all the estimates >> and actual timings then any tags which come with the <iostat> or >> <dtrace> option would just get mixed up with the estimates and timing >> info. > > FWIW, I like Greg's idea of subdividing the available data this way. > I'm no XML guru, so maybe there is a better way to do it --- but a > very large part of the reason for doing this at all is to have an > extensible format, and part of that IMHO is that client programs should > be able to have some rough idea of what things are even when they > don't know it exactly.
I like it too, but I'd like to see us come up with a design that allows it to be used for all of the output formats (text, XML, and JSON). I think it we should be looking for a way to allow modules to publish abstract objects like property-value mappings, or lists of strings, rather than thinking strictly in terms of XML. If we have a module called foo that emits property bar with value baz and property bletch with value quux, then in text format we can print: Module Foo: Bar: Bletch Baz: Quux In XML we can print: <Modules> <Module> <Module-Name>Foo</Module-Name> <Bar>Bletch</Bar> <Baz>Quux</Baz> </Module> </Modules> (or any of about 10 reasonable alternatives that are functionally identical) In JSON we can print "Modules" : [ { "Module Name" : "Foo", "Bar": "Bletch", "Baz": "Quux" } ] (or any of about 2 reasonable alternatives that are functionally identical) If we start thinking in terms of "provide an API to insert XML into the XML-format output", we get back to my original complaint: if the only way of getting additional data is to piece through the XML output, then we'll quickly reach the point where users need XSLT and stylesheets to extract the data they care about. I think that's an annoyance that is easily avoidable. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers