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