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
