Re: machine-readable explain output v4

On Mon, Aug 10, 2009 at 1:56 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Revised patch attached.  I'm not convinced this is as good as it can
>> be, but I've been looking at this patch for so long that I'm starting
>> to get cross-eyed, and I'd like to Tom at least have a look at this
>> and assess it before we run out of CommitFest.
>
> Committed after significant hacking to try to make the format
> abstraction layer a tad more complete.

Looks nice, thank you.

> There are still some open issues:
>
> * I still think we need a written spec for the non-text output formats.
> One of the problems with machine reading of the text format is you have
> to reverse-engineer what the possibilities are, and this patch hasn't
> made that better.  A list of the possible fields, and the possible
> values for those fields that have finite domains, would be a start.

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

> * 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.

> * 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 ?

> * 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.
>
> Anyway, it's committed so that people can play with it.  We're a
> lot more likely to get feedback if people actually try to use the
> feature.

Awesome.

...Robert