Re: Adding a --quiet option to initdb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Adding a --quiet option to initdb
Дата
Msg-id 2198.1138374540@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Adding a --quiet option to initdb  (Thomas Hallgren <thomas@tada.se>)
Ответы Re: Adding a --quiet option to initdb  (Thomas Hallgren <thomas@tada.se>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: stats for failed transactions (was Re: [GENERAL] VACUUM Question)
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Proposal: new pg_dump options --copy-delimiter and