Re: Adding a --quiet option to initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Adding a --quiet option to initdb
Date
Msg-id 2198.1138374540@sss.pgh.pa.us
Whole thread Raw
In response to Re: Adding a --quiet option to initdb  (Thomas Hallgren <thomas@tada.se>)
Responses Re: Adding a --quiet option to initdb  (Thomas Hallgren <thomas@tada.se>)
List pgsql-hackers
Thomas Hallgren <thomas@tada.se> writes:
> This is how I perceive the output from initdb:

> - The output lists settings for locale, encoding and buffer usage. Why 
> are these specific settings be of special interest? Anyone with an 
> interest in them knows where to find them anyway. This information is 
> not important.
> - It lists (the successful creation of ) the internal directory 
> structure of the data directory. This information is not important.
> - Some output is purely educational and thus belongs in the manual, not 
> in a command output ("This user must also own the server process", "You 
> can now start the database..."). This information is not important.
> - Lot's of info is printed about successful creation of configuration 
> files, template databases, conversions, information schema, system 
> views, that pg_authid and dependencies has been initialized, database 
> copying, etc. This information is not important.

> I still think it's much better to have complete silence unless there are 
> warnings and/or errors. That makes them much easier to spot. Right now I 
> get a "WARNING: enabling "trust" authentication for local connections". 
> Now this information *is* important. Unfortunately it's mixed in with 
> all the rest unless I use a special redirect of stdout.

To apply your own argument, why is that important?  Anyone with an 
interest in the authentication settings knows where to find them anyway.

While we can probably all agree that it's not very interesting to
mention every single directory that initdb creates, I find it fairly
hard to buy an argument that some of the non-progress messages are
important and the others are not.  Every one of them got put in
because someone thought it important.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: stats for failed transactions (was Re: [GENERAL] VACUUM Question)
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Proposal: new pg_dump options --copy-delimiter and