Re: machine-readable explain output v4

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 10, 2009 at 1:56 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There are still some open issues:
>>
>> * I still think we need a written spec for the non-text output formats.

> Where would we put this in the documentation? Seems like it might
> need a new section/chapter somewhere.

I think it'd be sufficient to put it on the EXPLAIN reference page.
IIRC, the COPY data format is documented on COPY's reference page,
and this is equally particular to a single SQL command.

>> * There are some decisions that seem a bit questionable to me, like
>> using "Parent Relationship" tags rather than having the child plans
>> as labeled attributes of the parent node. But I can't really evaluate
>> this for lack of experience with designing XML/JSON structures.

> That would work for XML, but I think it doesn't for JSON.

Why not? Something like

"Inner": { ... }

fits in JSON AFAICS. I don't know if there are any recognized style
guidelines in the structured-document world that would approve or
deprecate the way you've done it. I do see the advantage that code
can visit all the subplans of a plan without knowing much about the
plan tree structure. What's bothering me the most is that member
subplans of an Append are mushed together with other child plan types.
The ordering of the members is significant. Now the chosen
representation does preserve that order, but ISTM mushing all the
child plan types together like this makes it *look* like the Plans
attribute is unordered; especially when the ordering is in fact
not significant for every other child plan type.

>> * As already noted, the URL for the XML schema seems questionable.
>> I think that versioning should go more like v1, v2, ... instead of
>> being tied to a year.

> Or what about being based on the major PostgreSQL major version?
> Would it be lame to think about something like
> http://www.postgresql.org/docs/8.5/static/sql-explain.html ?

Yeah. In the first place, I imagine the schema will change a few times
before 8.5 is released. In the second, once we do get it right it'll
probably be stable across multiple releases. I think we should just
have a serial number on them, and not assume that either years or
releases are appropriate quantifiers.

>> * I complained earlier that I thought dumping expressions as text
>> was pretty bogus --- it'll leave anything that's trying to
>> do analysis in depth still having to parse complicated stuff.
>> I don't know exactly what I want instead, but at the very least it
>> seems like the variables used in an expression ought to be more
>> readily available.

On this point: basically what's bothering me is that by dumping
expressions as undifferentiated text blobs, we are making the same
mistake in small that this patch is meant to solve in large.
I don't really want to do the work of decomposing expressions right
now, but I'm not happy that it's impossible to do so without a
non-backwards-compatible DTD break. What do you think of emitting
expressions as containers, with the text as the only property?
Instead of

<Filter>(f1 &gt; 0)</Filter>

something like

<Filter><Expr><Text>(f1 &gt; 0)</Text></Expr></Filter>

This would leave room to add additional properties beside the text,
and not break existing clients when we do it.

Another issue that bothers me a bit is the "Strategy" field.
It may or may not appear depending on "Node Type", and when it
does appear, the possible values vary depending on "Node Type".
Is that sort of non-orthogonality considered good style?

regards, tom lane