Re:

On Tue, Jan 7, 2014 at 10:55 PM, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> wrote:
> Below attached patch is implementing following todo item..
>
> machine-readable pg_controldata?
>
> http://www.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
>
> Possible approaches:
>
> 1. Implement as backend function and provide a view to user.

I think this would be useful.

> - But In this approach user can only get this information when
> server is running.

That is true, but we also have the command-line tool for when it isn't.

> 2. Extend pg_controldata tool to provide value of an individual
> attribute.
>
> A first draft version of the patch is attached in the mail, implemented
> using approach 2.

I think this is really ugly, and I don't see what it accomplishes. If
the user wants only one setting from pg_controldata, they can just
grep for the line that contains that value. You mention that the
patch skips printing the name of the field, avoiding parsing
difficulties for the user, but the parsing here is trivial: just skip
everything up to the first colon, plus any subsequent whitespace.

It's worth keeping in mind that the information in pg_controldata is,
by and large, not something we expect users to need all the time. Are
there use cases for wanting to look at it? Sure. But not a ton of
them. If we thought that everyone who works with PostgreSQL would
need to write a script to fetch, say, the catalog version number, then
it might be worth having pg_controldata --catalog-version to make that
easy so that everyone doesn't have to write pg_controldata | grep
'^Catalog version' | sed 's/.*: *//' , but considering that it's only
something that comes up rarely, I don't really think it's worth the
extra code and documentation to add an option for it. And similarly
for the other pg_controldata fields.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company