Re: generic options for explain - Mailing list pgsql-hackers

From Robert Haas
Subject Re: generic options for explain
Date
Msg-id 603c8f070905261053g4bdebf67nee426f9c4ce545d6@mail.gmail.com
Whole thread Raw
In response to Re: generic options for explain  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: generic options for explain  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> 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. :-)

Yeah, that's fine.  I think we should target 4/1/2010 as the
submission date for that stylesheet.  :-)

> 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.

Yes, I think there is an excellent case for being able to stash any
output format into a table.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
Next
From: Gevik Babakhani
Date:
Subject: Re: usability of pg_get_function_arguments