Re: pg_controldata gobbledygook

On Thu, Apr 25, 2013 at 9:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote:
>>> I think I've heard of scripts grepping the output of pg_controldata for
>>> this that or the other. Any rewording of the labels would break that.
>>> While I'm not opposed to improving the labels, I would vote against your
>>> second, abbreviated scheme because it would make things ambiguous for
>>> simple grep-based scripts.
>
>> We could provide two alternative outputs, one for human consumption with
>> the proposed format and something else that uses, say, shell assignment
>> syntax. (I did propose this years ago and I might have an unfinished
>> patch still lingering about somewhere.)
>
> And a script would use that how? "pg_controldata --machine-friendly"
> would fail outright on older versions. I think it's okay to ask script
> writers to write
> pg_controldata | grep -e 'old label|new label'
> but not okay to ask them to deal with anything as complicated as trying
> a switch to see if it works or not.

From what I'm reading, it seems like the main benefit of the changes
is to make things easier for humans to skim over. Automated programs
that care about precise meanings of each field are awkwardly but
otherwise well-served by the precise output as rendered right now.

What about doing something similar but different from the
--machine-readable proposal, such as adding an option for the
*human*-readable variant that is guaranteed to mercilessly change as
human-readers/-hackers sees fit on whim? It's a bit of a kludge that
this is not the default, but would prevent having to serve two quite
different masters with the same output.

Although I'm not seriously proposing explicitly "-h" (as seen in some
GNU programs in rendering byte sizes and the like...yet could be
confused for 'help'), something like that may serve as prior art.