Devrim GUNDUZ wrote:
> Hi,
>
> On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
>> Devrim GUNDUZ <devrim@commandprompt.com> writes:
>>> Attached is a patch which adds --quiet and --q option to initdb.
>> Why is this a good idea?
>
> I was playing with 8.2 RPM init script and thought that instead of
> directing the output to /dev/null, it would be better to use a command
> line option for that. Also, we are designing a new installer project and
> --quiet might help us.
>
> I would rise this idea in -hackers before providing a patch, but since
> this is my first patch, I thought it would be a good exercise for me.
>
> Regards,

Most *nix commands are quiet by default. Most windows commands are verbose and some of them
can be made to shut up using special '--quite' like options. Other can't even do that.

Personally, I think initdb (and most other commands as well) should be silent unless
something goes wrong or unless I explicitly tell it to be verbose. In other words, don't
repeat bad practices from Windows by introducing --quiet. Make it completely silent by
default instead and then introduce a --verbose.

Regards,
Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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 information of iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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.

Plus it can be a fairly long-running process on slower machines, so
providing feedback to the user is good.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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.
>>
>>
>
>Plus it can be a fairly long-running process on slower machines, so
>providing feedback to the user is good.
>
>

Moreover, we should not change behaviour just on aesthetic grounds. For
example, if initdb were suddenly to become quiet by default, we would
need to add some version-specific processing to the buildfarm.

As for a --quiet option, I just don't see why it is needed when
>/dev/null works perfectly well.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
>
>> 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.
>

I see your point, and sure, this is just the result of PostgreSQL
default behavior so the warning is unnecessary. It's all in the admin
guide anyway. If the default behavior really calls for a warning, then
the default behavior should change. My original line of though was that
the warning was important since it is about a possible security
vulnerability (it's printed on stderr rather than stdout where all the
rest ends up so I'm not the only one making the distinction).

> 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.
>
>
I agree. The above warning is not an indication that something is wrong
and it should be removed too.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Thomas Hallgren wrote:
> Tom Lane wrote:
> >
> >>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.

> >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.
>
> I agree. The above warning is not an indication that something is wrong
> and it should be removed too.

This warning was added because of security considerations AFAIR. If the
intent is to make initdb super-quiet, we still have to have security in
mind. So if you want it to not say anything by default, instead of
throwing a warning it should throw an error and refuse to continue;
unless a default password is specified or a --silently-enable-trust-auth
switch is passed, in either of which cases it can silently continue.

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"I can't go to a restaurant and order food because I keep looking at the
fonts on the menu. Five minutes later I realize that it's also talking
about food" (Donald Knuth)

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> This warning was added because of security considerations AFAIR. If the
> intent is to make initdb super-quiet, we still have to have security in
> mind. So if you want it to not say anything by default, instead of
> throwing a warning it should throw an error and refuse to continue;
> unless a default password is specified or a --silently-enable-trust-auth
> switch is passed, in either of which cases it can silently continue.

There is 0 chance that we will design initdb to fail by default.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings