Re: Pg default's verbosity? - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Pg default's verbosity?
Date
Msg-id alpine.DEB.2.02.1206162021520.2962@localhost6.localdomain6
Whole thread Raw
In response to Re: Pg default's verbosity?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Pg default's verbosity?
List pgsql-hackers
Hello Tom,

thanks for your answer.

>> So I would suggest the following todos:
>> 1 - change the default verbosity to "warning".
>
> The argument for defaulting to NOTICE is the same as it's always been:
> that those messages are really intended for novices, and a pretty good
> definition of a novice is somebody who doesn't know how to (or that he
> should) change the verbosity setting.  So if we don't show notices by
> default, they will be unavailable to exactly the people who need them.
> Your proposal does not overcome this argument.

I'm sceptical about what a real "novice" is expected to do about the 
incredible flow of useless information displayed when loading a 
significant script. For a start, s?he should be an incredibly fast 
reader:-)

For a non-novice it just hides what is important and should be seen.

However maybe it make senses in interactive mode, as you suggest, so 
possibly this should be the real trigger to change the level of messages.

> Besides, I'm not convinced that changing client_min_messages in
> isolation would do much for the problem,

I agree with you, but it is a necessary step somewhere...

> because psql is still pretty chatty by itself; you really need -q to 
> have any hope that important messages didn't scroll off your screen.

Hmmm, yes and no, in my opinion. "CREATE XXX" is a very short output, 
quite distinct from the output of a warning/error, which can be seen when 
messages are scrolled, even if the message cannot be read on the fly. I 
would know that something is not right.

> Perhaps it would be sensible to have the -q switch also execute "set 
> client_min_messages = warning", and recommend that people use that when 
> running allegedly-debugged scripts?

That could be useful. However I'm not sure that I would select -q when 
loading a big script, I'm happy to know that things are going on and I 
would like to know if the script is stuck somewhere.

>> 2 - change -1 to work on stdin as well instead of being ignored,
>>      or provide another option that would do that.
>
> Yeah, if that doesn't work already,

I did checked that it does not work with 9.1.3.

> it would be sane to make it do so, at least for non-tty stdin.  It seems 
> like a fairly bad idea for interactive stdin, though.

I agree that distinguishing interactive & non interactive stdin is 
reasonable.

So maybe the suggestion would be to distinguish 2 default settings - client_min_tty_messages = notice; # or some other
name...- client_min_messages = warning; # or some other name...
 

Moreover:
 - "-1" should work on stdin *when not interactive* - -1 should be clearly advised when loading scripts...   not sure
whereit should be in the documentation... - I'm not sure about "-q" for this purpose, mostly because   I would not use
itby default
 

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: SQL standard changed behavior of ON UPDATE SET NULL/SET DEFAULT?
Next
From: Daniel Farina
Date:
Subject: Re: Streaming-only Remastering