Re: Pg default's verbosity?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pg default's verbosity?
Date: 2012-06-16 18:56:40
Message-ID: alpine.DEB.2.02.1206162021520.2962@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 where it should be in the documentation...
- I'm not sure about "-q" for this purpose, mostly because
I would not use it by default

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Singer 2012-06-16 19:03:20 Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture
Previous Message Daniel Farina 2012-06-16 18:56:05 Re: Streaming-only Remastering