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

From Greg Smith
Subject Re: YAML Was: CommitFest status/management
Date
Msg-id 4B1C7E00.9030308@2ndquadrant.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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: YAML Was: CommitFest status/management  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Robert Haas wrote:
> 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.
>   
It's not the case that JSON can be turned into YAML or that it just 
happens that it can be parsed by YAML parsers.  While there was some 
possible divergence in earlier versions, a JSON 1.2 document *is* in 
YAML format already.  JSON is actually a subset of YAML that uses one of 
the many possible YAML styles--basically, YAML accepts anything in JSON 
format, along with others.  This means that by providing JSON output, 
we've *already* provided YAML output, too.  Just not the nice looking 
output people tend to associate with YAML.

Accordingly, there is really no basis for this patch to exist from the 
perspective of helping a typical tool author.  If you want to parse YAML 
robustly, you're going to grab someone's parsing library to do it rather 
than writing it yourself, and if you do that it will accept the existing 
JSON output just fine too.  Basically this patch lives or dies by 
whether it looks so much nicer to people as to justify its code weight.

Given the above, I don't understand why writing this patch was deemed 
worthwhile in the first place, but I hate to tell people they can't have 
something they find visually appealing just because I don't think it's 
an improvement.  Consider me a neutral vote, although I suspect the 
above may sway some people who were on the fence toward disapproval.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: [patch] pg_ctl init extension
Next
From: Fujii Masao
Date:
Subject: Re: Reading recovery.conf earlier