Re: Little confusing things about client_min_messages.

Bruce Momjian <bruce@momjian.us> writes:
> On Sat, Mar  8, 2014 at 11:31:22AM -0500, Tom Lane wrote:
>> Tomonari Katsumata <t.katsumata1122@gmail.com> writes:
>>> [ client_min_messages = info is not documented ]

>> That's intentional, because it's not a useful setting.  Even more so
>> for the other two.

> Well, 'info' is between other settings we do document, so I am not clear
> why info should be excluded.  It is because we always output INFO to the
> client?  From elog.c:

>         if (ClientAuthInProgress)
>             output_to_client = (elevel >= ERROR);
>         else
>             output_to_client = (elevel >= client_min_messages ||
>                                 elevel == INFO);

Right, so if you did set it to that, it wouldn't be functionally different
from NOTICE.

I'm not real sure why we allow setting client_min_messages to FATAL or
PANIC at all; seems to me that would break the FE/BE protocol, which says
that command cycles end with either the expected response or ErrorMessage.
In some quick experimentation, libpq/psql don't seem to get as confused as
I thought they would; but the user is sure likely to.

regression=# select 1/0;
ERROR:  division by zero
regression=# set client_min_messages TO panic;
SET
regression=# select 1/0;
regression=# slect
regression-# ;
regression=# select 1.0;?column? 
----------     1.0
(1 row)

regression=# foo;
regression=# 

So no, I don't think we ought to be advertising these as suggested
values.  A saner proposed patch would be to remove them from the
valid values altogether.  We probably had some good reason for leaving
them in the list back when, but I'm having a hard time reconstructing
what that would be.
        regards, tom lane