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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
