Re: machine-readable explain output v4

On Sun, Aug 9, 2009 at 8:53 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On Monday 10 August 2009 01:21:35 Andrew Dunstan wrote:
>>> That ";" after the attribute is almost certainly wrong. This is a classic
>>> case of what I was talking about a month or two ago. Building up XML (or
>>> any structured doc, really, XML is not special in this regard) by ad hoc
>>> methods is horribly error prone. if you don't want to rely on libxml, then
>>> I think you need to develop a lightweight abstraction rather than just
>>> appending to a StringInfo.
>
>> While it would be possible to add another step inbetween and generate a format
>> neutral tree and generate the different formats out of it I am not sure that
>> this is worthwile.
>> The current text format will need to stay special cased anyway because its far
>> to inconsistent to generate it from anything abstract and I don't see any
>> completely new formats coming (i.e. not just optional parts)?
>
> The patch as-submitted does have a lightweight abstraction layer of
> sorts, but the main code line feels free to ignore that and hack around
> it.  I agree that we can't avoid special-casing the text output, but
> I'm trying to improve the encapsulation otherwise.  What I've got at the
> moment is attached.  I'd be interested in comments on the grouping
> notion in particular --- I reverse-engineered that out of what the code
> was doing, and I'm sure it could use improvement.

I haven't tested it but it looks pretty good to me. I probably should
have done something like this to begin with, but I fell into the trap
of being too timid about introducing new concepts.

One subtle point that isn't documented and probably should be is that
JSON can't support a container that behaves partly like a list and
partly like a hash, as XML can. So for example in XML a <Plan> tag
could have children like <Startup-Cost> (one each) and could also have
its inner, outer, and sub-plans in there as <Plan> tags right under
the parent <Plan>. I'm not sure this would be good design anyway, but
it COULD be done. In JSON, this will crash and burn, because the
container is either an array (which precludes labelling the elements)
or a hash (which precludes duplicates).

I've avoided this problem by introducing an additional layer of
grouping whenever this situation comes up; for symmetry it exists in
both output formats. So for example in the above-mentioned case the
<Plan> has a child called <Plans> which in turn contains each <Plan>
that belongs under the parent; in JSON, this maps nicely to a property
called "Plans" which points to an array of hashes, each of which
represents a plan.

We should probably have a long comment somewhere in explain.c
explaining all of this. It's the sort of thing that you figure out
you need to have when you're writing the code, but it might not be too
obvious reading the code after the fact. It's also a reason why I'm
really glad I decided to write two alternative output formats;
otherwise, I fear that we would have blundered into a bunch of
XML-isms that wouldn't have been translatable into anything else.

...Robert