Re: pg_controldata gobbledygook

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_controldata gobbledygook
Date: 2013-04-26 09:00:26
Message-ID: 517A422A.8070303@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26/04/13 18:53, Daniel Farina wrote:
> 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.
>
>
I think the current way should remain the default, as Daniel suggests
- but a '--human-readable' (or suitable abbreviation) flag could be added.

Such as in the command to list directory details, using the 'ls' command
in Linux...

(Below, *Y* = 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 1024
bytes = 2^80 bytes.)

*man ls**
**[...]**
** -h, --human-readable**
** with -l, print sizes in human readable format (e.g., 1K
234M 2G)**
**[...]**
** SIZE may be (or may be an integer optionally followed by) one
of fol-**
** lowing: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on
for G, T,**
** P, E, Z, Y.**
**[...]*

Cheers,
Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-04-26 09:08:10 Re: pg_controldata gobbledygook
Previous Message KONDO Mitsumasa 2013-04-26 08:51:30 Re: Failing start-up archive recovery at Standby mode in PG9.2.4