Thread: Re: [PATCHES] Explain XML patch v2

Re: [PATCHES] Explain XML patch v2

From
Tom Raney
Date:
Quoting daveg <daveg@sonic.net>:

> On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote:
>> On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote:
>> > It would also be interesting if EXPLAIN could optionally be a
>> > function that returns a datum of type XML, to allow further
>> > processing.
>>
>> It would be better to have a function which allows people to plug in
>> their own serialization.  A JSON or YAML one, for example, would be
>> much lighter weight on both ends.
>
> +1 for either of these.
>
> -dg
>

So, this leads me to the idea of assembling the EXPLAIN data
internally in an output-neutral data structure.  At the very end of
processing, one decision statement would decide which output plugin to
use for output.  Sprinkling XML print statements throughout the code
(as currently done in the patch) while functional, is not ideal.  And,
the escaping of XML content should ideally be done in the serializer
anyway.

Of course, this realization didn't occur to me until *after* I had
spent a bit of time coding up the patch in its current form.  Oh well.

Thoughts?

Regarding the XML datum, in order to support that, will all users need
to compile with libxml?  Are there any lighter weight solutions to
serialize other than libxml?

-Tom Raney




Re: [PATCHES] Explain XML patch v2

From
Peter Eisentraut
Date:
Am Freitag, 4. Juli 2008 schrieb Tom Raney:
> Regarding the XML datum, in order to support that, will all users need  
> to compile with libxml?  Are there any lighter weight solutions to  
> serialize other than libxml?

You can create XML without libxml.

Re: [PATCHES] Explain XML patch v2

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Freitag, 4. Juli 2008 schrieb Tom Raney:
>> Regarding the XML datum, in order to support that, will all users need �
>> to compile with libxml? �Are there any lighter weight solutions to �
>> serialize other than libxml?

> You can create XML without libxml.

Seems to me that anyone who wants this feature will probably also want
the existing libxml-based features, so they'll be building with libxml
anyway.  So I'd not be in favor of expending any extra code on a
roll-your-own solution.

            regards, tom lane