Re: generic options for explain

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Dave Page <dpage(at)pgadmin(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: generic options for explain
Date: 2009-05-26 17:53:33
Message-ID: 603c8f070905261053g4bdebf67nee426f9c4ce545d6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gevik Babakhani 2009-05-26 17:58:55 Re: usability of pg_get_function_arguments
Previous Message Robert Haas 2009-05-26 17:49:03 Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)