Re: generic options for explain

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