Re: machine-readable explain output

On 06/16/2009 09:51 PM, Robert Haas wrote:
> On Tue, Jun 16, 2009 at 2:12 PM, Tom Lane<tgl@sss.pgh.pa.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