Re: YAML Was: CommitFest status/management - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: YAML Was: CommitFest status/management
Date
Msg-id 4B19AC68.50902@agliodbs.com
Whole thread Raw
In response to Re: YAML Was: CommitFest status/management  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: YAML Was: CommitFest status/management  (Robert Haas <robertmhaas@gmail.com>)
Re: YAML Was: CommitFest status/management  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Re: YAML Was: CommitFest status/management  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
> On top of that, if you did want YAML for easier readability, what
> aspect of the output is more readable in YAML than it is in text
> format?  The only answer I can think of is that you like having each
> data element on a separate line, so that the plan is much longer but
> somewhat narrower.  But if that's what you want, the JSON output is
> almost as good - the only difference is a bit of extra punctuation.

"almost as good" ... I agree with Kevin that it's more readable.

The whole patch just adds 144 lines.  It doesn't look to me like there's
significant maintenance burden involved, but of course I need to defer
to the more experienced.  It's even possible that we could reduce the
size of the patch still further if we really looked at it as just a
differently punctuated JSON.

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.

Again, if there were a sensible way to do YAML as a contrib module, I'd
go for that, but there isn't.

--Josh Berkus


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: YAML Was: CommitFest status/management
Next
From: Michael Glaesemann
Date:
Subject: Re: New VACUUM FULL