Re: machine-readable explain output
От | Andres Freund |
---|---|
Тема | Re: machine-readable explain output |
Дата | |
Msg-id | 4A37AC96.5000103@anarazel.de обсуждение исходный текст |
Ответ на | Re: machine-readable explain output (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: machine-readable explain output
Re: machine-readable explain output |
Список | pgsql-hackers |
On 06/16/2009 03:45 PM, Andrew Dunstan wrote:>> 3. We have existing precedent for this design pattern in, e.g.>> table_to_xml>>http://www.postgresql.org/docs/current/interactive/functions-xml.html> Tables are flat, explain output is not. Comparing Greg's approach with Robert's it seems to me that Robert's approach isn't flatter than Greg's - it just relies more on nodes. > If there is a relationship between the items then that needs to be > expressed in the XML structure, either by use of child nodes or > attributes. Relying on the sequence of nodes, if that's what you're > doing, is not a good idea, and will make postprocessing the XML using > XSLT, for example, quite a bit harder. (Processing a foo that comes > after a bar is possible but not as natural as processing a foo that is a > child or attribute of a bar) How would you model something like: <plans> <plan> ... </plan> <plan> ... </plan> ... </plans> otherwise? There are potentially unlimited number of child nodes - AppendNode for example can have any number of them. Sure, you can give each <plan> node a 'offset=' id, but that doesn't buy much. I don't see how that could be much improved by using child-nodes (or even worse attributes). That is as far as I have seen the only place where the format relies on the sequence of nodes. > Anyway, I think what this discussion points out is that we actually need > a formal XML Schema for this output. Agreed. If helpful I can create a schema for the current format. Andres
В списке pgsql-hackers по дате отправления: