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

From James William Pye
Subject Re: Adding a --quiet option to initdb
Date
Msg-id 1138216838.978.243.camel@ICRH41.ic.aiall
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
List pgsql-hackers
On Wed, 2006-01-25 at 19:23 +0100, Thomas Hallgren wrote:
> Make it completely silent by
> default instead and then introduce a --verbose.

+1.

I imagine initdb is usually ran interactively, so I don't think having
the extra output is a big issue considering the normal case, but I think
the "If you want it, ask for it" idea that Thomas is proposing is the
right way. Why should initdb give it [processing information] to the
user if the user didn't request it in the first place?


For applications that want to automate the initdb process in a GUI-way
or whatnot, the output [of initdb] isn't likely to be a very elegant
aspect of the environment the developer would be trying to create, but
they are, more or less, stuck with getting it if they wish to provide
their user with more informative feedback about the ongoing process.

While for Devrim's case, it would be overkill, but what about a
"libinitdb", or some sort authoritative source of processing steps in
order to initialize a new database location that other applications
could make easier use of?
--
Regards, James William Pye

iCrossing Privileged and Confidential Information
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged
informationof iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intendedrecipient, please contact the sender by reply email and destroy all copies of the original message. 




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cleaning up the INET/CIDR mess
Next
From: "Matthew D. Fuller"
Date:
Subject: Re: Cleaning up the INET/CIDR mess