Re: YAML Was: CommitFest status/management

On Sun, Dec 6, 2009 at 8:34 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>
> Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Having compared the JSON and YAML output formats, I think having YAML as
>> a 2nd human-readable format might be valuable, even though it adds
>> nothing to machine-processing.
>
> Sure. YAML is human readable and can print more information that is
> too verbose in one-line text format. +1 to add YAML format to EXPLAIN.
>
>> Again, if there were a sensible way to do YAML as a contrib module, I'd
>> go for that, but there isn't.
>
> Some ideas to export formatters:
>  1. Provides register_explain_format(name, handler) function.
>    Contrib modules can register their handlers when LOADed.
>
>  2. Provides a method to specify a filter function. XML output is
>    passed to the function and probably converted with XSLT.
>
> BTW, an extensible formatter is surely useful, but what will we do about
> XML and JSON formats when we have it? Will we remove them from core?
> If we have a plan to the direction, we should complete it before 8.5.0
> release. We will be hard to revert them after the release.

I sent a previous message about this, but just realized I forgot to
copy the list. I thought about the possibility of a pluggable system
for formats when I wrote the original machine-readable explain patch.
It seemed to me at the time that if we went this route any contrib
module would have to duplicate significant portions of explain.c, no
matter where we put the hooks. We'd presumably feel obliged to update
the contrib module when making any changes to explain.c, so I think
the maintenance burden would actually be higher that way than with
everything in core.

The main point here for me is that the JSON format is already
parseable by YAML parsers, and can probably be turned into YAML using
a very short Perl script - possibly even using a sed script. I think
that it's overkill to support two formats that are that similar.

Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan,
Josh Drake, and myself arguing against including this in core, and
Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed
somewhat in favor of it in his message on-list but sent a message
off-list taking the opposite position. Brendan Jurd cast aspersions
on the human-readability of the text format but didn't explicitly take
a position on the core issue, and Euler Taveira de Oliveira suggested
that writing a converter would be easier than writing a module
framework (which I think is almost certainly true) but also didn't
explicitly take a position on the core issue.

Overall, that sounds to me like a slight preponderance of "no" votes.
Anyone think I've mis-tallied or want to weigh in?

...Robert