Re: Adding a --quiet option to initdb

Jim C. Nasby wrote:
> On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote:
>
>> James William Pye wrote:
>>
>>> Why should initdb give it [processing
>>> information] to the user if the user didn't request it in the first
>>> place?
>>>
>> Because it shows important information that we want the user to see.
>>
>
>
If you're serious about the "important information that we want the user
to see", then you need to really think about what's important (see
argument below). Otherwise, the output becomes a text-blurb that nobody
reads.

> Plus it can be a fairly long-running process on slower machines, so
> providing feedback to the user is good.
>
Good point, and well covered if a --verbose option is introduced.

What is "important information"? What makes the user really see it?

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.

Regards,
Thomas Hallgren