Re: pg_controldata gobbledygook
От | Gavin Flower |
---|---|
Тема | Re: pg_controldata gobbledygook |
Дата | |
Msg-id | 517A422A.8070303@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: pg_controldata gobbledygook (Daniel Farina <daniel@heroku.com>) |
Список | pgsql-hackers |
<div class="moz-cite-prefix">On 26/04/13 18:53, Daniel Farina wrote:<br /></div><blockquote cite="mid:CAAZKuFa5ougGqfy+z6SpMB+ppCy3Oxq1xP1X4ekEgVvj4Zt2cQ@mail.gmail.com"type="cite"><pre wrap="">On Thu, Apr 25, 2013at 9:34 PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a> wrote: </pre><blockquote type="cite"><pre wrap="">Alvaro Herrera <a class="moz-txt-link-rfc2396E" href="mailto:alvherre@2ndquadrant.com"><alvherre@2ndquadrant.com></a>writes: </pre><blockquote type="cite"><pre wrap="">Tom Lane wrote: </pre><blockquote type="cite"><pre wrap="">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. </pre></blockquote></blockquote><pre wrap=""> </pre><blockquote type="cite"><pre wrap="">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.) </pre></blockquote><pre wrap=""> 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. </pre></blockquote><pre wrap=""> 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. </pre></blockquote> I think the current way should remain the default, as Daniel suggests - but a '--human-readable' (orsuitable abbreviation) flag could be added.<br /><br /> Such as in the command to list directory details, using the 'ls'command in Linux...<br /><br /><br /> (Below, <tt><small><b>Y</b></small></tt> = 1024 * 1024 * 1024 * 1024 * 1024 * 1024* 1024 * 1024 bytes = 2^80 bytes.)<br /><br /><small><b><tt>man ls</tt></b><b><tt><br /></tt></b><b><tt>[...]</tt></b><b><tt><br/></tt></b><b><tt> -h, --human-readable</tt></b><b><tt><br /></tt></b><b><tt> with -l, print sizes in human readable format (e.g., 1K 234M 2G)</tt></b><b><tt><br /></tt></b><b><tt>[...]</tt></b><b><tt><br /></tt></b><b><tt> SIZE may be (or may be an integer optionally followedby) one of fol‐</tt></b><b><tt><br /></tt></b><b><tt> lowing: KB 1000, K 1024, MB 1000*1000, M 1024*1024, andso on for G, T,</tt></b><b><tt><br /></tt></b><b><tt> P, E, Z, Y.</tt></b><b><tt><br /></tt></b><b><tt> [...]</tt></b></small><br/><br /><br /> Cheers,<br /> Gavin<br />
В списке pgsql-hackers по дате отправления:
Предыдущее
От: KONDO MitsumasaДата:
Сообщение: Re: Failing start-up archive recovery at Standby mode in PG9.2.4