Re: machine-readable explain output

On Fri, Jun 12, 2009 at 5:13 PM, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
> Josh Berkus wrote:
>>
>>> How would you go about extracting the XML/JSON bits from the rest of
>>> what is in the log file?  (apologies if this is a question I should
>>> already know the answer to)
>>
>> If you do CSV output, it's in a field.
>
> And even if it's not, a well formed XML document would be fairly easy to
> extract, especially if the root element is well known (e.g. <pg:explain> or
> some such). And if the patch doesn't produce a well-formed XML doc then it
> needs work ;-). It might be nice if Robert were to post some samples of the
> output.

<pgexplain>, as it happens... I could post some samples of the
output, but it seems like it might be just as well to let those who
are curious try it for themselves. I'd rather get opinions from
people who care enough to download & test than from those who are just
bikeshedding. :-)

> Quick question: does the patch use formal methods using, say, the DOM API to
> build up the XML, or informal methods  (like foo.append('<element>');
> foo.append(content); foo.append('</element>'); )
>
> As you can tell, I haven't looked over it yet. But I intend to ;-)

Use the Source, Luke. :-)

But, it's informal methods. I don't see a lot of value in doing it
the other way, though perhaps I could be convinced otherwise. One
thing that's nice about the way it works now is that the only support
function it requires is a basic XML-escaping function, which it turns
out we already have in the PG sources anyway, though not in a quite
usable form (the infrastructure patch deals with the necessary
adjustments). So you can explain (format xml) even if you compile
without --with-libxml.

If you want to see how the actual XML/JSON stuff works, you might want
to start with the last patch in the series (explain_format). If you
want to commit it, a course of action to which I can give my unbiased
endorsement, then you'll want to start with explain_refactor.

...Robert