Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably Java and
others) use. As a simple example, if you have a hash like { a => 1, b
=> 2 } (using the Perl syntax) you can map it to
<hash><a>1</a><b>2</b></hash>. That's easy to generate, but the
reverse transformation is full of error-handling cases, like
<hash><a>1</a><b>2<c/></b></hash> and <hash><a>1</a><a>2</a></hash>.
I'm sure experienced XML hackers have ways to work around these
problems, but the XML libraries I've worked with basically don't even
try to turn the thing into any sort of general-purpose data structure.
They just let you ask questions like "What is the root element? OK,
now what elements does it contain? OK, there's an <a> tag there, what
does that have inside it? Any more-deeply-nested tags?". On the
other hand, JSON is explicitly designed to serialize and deserialize
data structures of this type, and it pretty much just works, even
between completely different programming languages.
Since we will be controlling the XML output, we can restrict it to a
form that is equivalent to what JSON and similar serialisation languages
use. We can even produce an XSD schema specifying what is allowed, if
anyone is so minded, and a validating parser could be told to validate
the XML against that schema. And XSLT processing is a very powerful
transformation tool. We could even provide a stylesheet that would turn
the XML into JSON. :-)
Anyway, I think we're getting closer to consensus here.
I think there's a good case for being able to stash the EXPLAIN output
in a table as XML - that way we could slice and dice it several ways
without having to rerun the EXPLAIN.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
