From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: machine-readable explain output |
Date: | 2009-06-16 21:26:21 |
Message-ID: | 4A380DFD.4020901@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/16/2009 09:51 PM, Robert Haas wrote:
> On Tue, Jun 16, 2009 at 2:12 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The main point here is that we have a pretty good idea of what
>> general-purpose client code is likely to want to do with the data,
>> and in a lot of cases that does not translate to having to know
>> each node type explicitly, so long as it can be categorized.
> I agree. I'm just not seeing the need for an *explicit*
> categorization contained within the data itself. For one thing,
> AIUI, that's the job of things like an XML Schema, which Andres
> Freund has already agreed to write, and I would expect that would be
> of some value to tool-writers, else why are we creating it?
It defines how exactly the output has to look - thats not easily
readable out of explain.c - so anything that could be created and
validated with that schema should be acceptable by $tool - even if
explain may not create it.
Just like EBNF or similar for other languages.
It does not help categorizing values in planner/execution/whatever
categories automatedly by some tool though.
I attached a simple relaxng schema - if somebody likes another format
that should be generatable out of that (using trang). It surely could
use some more work, but I think its detailed enough for now.
> I also think scalars and lists are recognizable without any
> particular additional markup at all, just by introspection of the
> contents.
That somewhat defies the usage of a strictly structured format? Perhaps
I am misunderstanding you though.
On another note it may be interesting to emit the current options to
explain in xml/json format - although that depends whether the option
syntax will be accepted.
Writing the schema I noticed something else I did not like about the
current format:
<Triggers>
<Trigger>
<Trigger>Name</Trigger>
or:
<Constraint>ConstraintName</Constraint>
</Trigger>
</Triggers>
The double usage of "<Trigger/>" seems to be somewhat ugly. Renaming it
to <TriggerName>/<ConstraintName> seems to be a good idea - at least
when staying at the current tag oriented style.
Andres
Attachment | Content-Type | Size |
---|---|---|
explain-schema.rng | text/plain | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-06-16 21:33:12 | Re: concurrent COPY performance |
Previous Message | Robert Haas | 2009-06-16 19:51:37 | Re: machine-readable explain output |