On Fri, Dec 4, 2009 at 7:42 PM, Josh Berkus <j...@agliodbs.com> wrote: >> 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.
I don't think the maintenance burden is the issue, per se. It's more that I don't like the idea of putting in a bunch of formats that are only trivially different from each other, and if there were ever a case where we should reject a new format because it is too similar to an existing one, this seems to be it. If that's a bad reason for rejecting a new format, then I don't have a second one, but we may end up with a lot of formats - and that WILL be a maintenance burden, especially if we ever want to make non-trivial extensions to the output format. Frankly, just adding new fields (perhaps controlled by new options) is never going to be that big of a deal, but there will certainly come a day when someone wants to do something more novel, like dumping parse-tree representations of expressions or something along the line of Tom Raney's visual explain tool, which dumped out every path the planner considered. I don't really want to be the person who has to tell the person who writes that patch "sorry, but we have to reject your patch until it supports every one of our numerous slightly different output formats". One possibility for contrib-module-izing this, and perhaps other output formats that people might like to see, is to write a function that takes the JSON or XML output as input and does the appropriate translation. For something like YAML, whose semantics are so close to JSON, this should be pretty simple. One of the reasons why I was hot to get JSON support into the initial version of machine-readable EXPLAIN is because JSON maps very cleanly onto the type of data structures that are common in scripting languages: everything is lists and hashes, nested inside each other, and text and numeric scalars. So you can read a JSON object into a script written in Perl, PHP, Python, Ruby, JavaScript, and probably half a dozen other languages and get a native object. From there, it's very easy to write the data back out in whatever format you happen to prefer just by walking the data structure. I suspect that a JSON-to-YAML converter in Perl would be less than 50 lines. (The XML format can also be transformed using things like XSLT, but I'm less familiar with those tools.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
