Bruce Momjian <br...@momjian.us> writes:
> On Sat, Mar 8, 2014 at 11:31:22AM -0500, Tom Lane wrote:
>> Tomonari Katsumata <t.katsumata1...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
