Re: Little confusing things about client_min_messages.

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Sat, Mar 8, 2014 at 11:31:22AM -0500, Tom Lane wrote:
>> Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)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