Обсуждение: BUG #5656: parameter 'client_min_messages' accept values not listed in enumvals

The following bug has been logged online:

Bug reference:      5656
Logged by:          thommy
Email address:      der.thommy@gmx.net
PostgreSQL version: 9.0rc1
Operating system:   Windows
Description:        parameter 'client_min_messages' accept values not listed
in enumvals
Details:

Hi there,

I just came across a small inconsistency:

pg=# select enumvals from pg_settings where name='client_min_messages';
                           enumvals
---------------------------------------------------------------
 {debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}



Hmm, according to the documentation 'panic' is a valid value...



pg=# select set_config('client_min_messages', 'PANIC', false);
 set_config
------------
 panic



pg=# select name, setting, enumvals from pg_settings where
name='client_min_messages';
-[ RECORD 1 ]-----------------------------------------------------------
name     | client_min_messages
setting  | panic
enumvals | {debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}



Maybe this can be fixed before the final release of 9.0

Regards, thommy

"thommy" <der.thommy@gmx.net> writes:
> I just came across a small inconsistency:

> pg=# select enumvals from pg_settings where name='client_min_messages';
>                            enumvals
> ---------------------------------------------------------------
>  {debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}

It's intentional that PANIC isn't listed there (nor is FATAL),
on the grounds that it's not really a useful setting.

            regards, tom lane

Tom Lane escreveu:
> "thommy" <der.thommy@gmx.net> writes:
>> I just came across a small inconsistency:
>
>> pg=# select enumvals from pg_settings where name='client_min_messages';
>>                            enumvals
>> ---------------------------------------------------------------
>>  {debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}
>
> It's intentional that PANIC isn't listed there (nor is FATAL),
> on the grounds that it's not really a useful setting.
>
Fine. But shouldn't we remove these options from docs and/or code?


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira wrote:
> Tom Lane escreveu:
> > "thommy" <der.thommy@gmx.net> writes:
> >> I just came across a small inconsistency:
> >
> >> pg=# select enumvals from pg_settings where name='client_min_messages';
> >>                            enumvals
> >> ---------------------------------------------------------------
> >>  {debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}
> >
> > It's intentional that PANIC isn't listed there (nor is FATAL),
> > on the grounds that it's not really a useful setting.
> >
> Fine. But shouldn't we remove these options from docs and/or code?

We are basically reusing the same validation code for this and other
min_messages settings.  Is it worth creating a custom one just for
client_min_messages?  Probably not.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Bruce Momjian escreveu:
> We are basically reusing the same validation code for this and other
> min_messages settings.
>
No, we have two enums ({client,server}_message_level_options); I don't
understand why we should have these options in client_min_messages enum.

--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira <euler@timbira.com> writes:
> Bruce Momjian escreveu:
>> We are basically reusing the same validation code for this and other
>> min_messages settings.
>>
> No, we have two enums ({client,server}_message_level_options); I don't
> understand why we should have these options in client_min_messages enum.

I believe the reasoning was that we shouldn't arbitrarily refuse values
that have a legal interpretation, but that we should hide them in the
pg_settings view if they aren't especially sensible to use.  You might
care to go back and consult the archives for the discussions that led up
to putting a "hidden value" feature into the guc-enum code.  ISTM your
argument can be reduced to "there should be no hidden values ever", but
I doubt we're going to buy that.

            regards, tom lane

Tom Lane escreveu:
> ISTM your
> argument can be reduced to "there should be no hidden values ever", but
> I doubt we're going to buy that.
>
No, the "hidden values" has their use case (hiding legal values that we don't
want to expose, for example, true/false, 0/1, yes/no). My point is if they are
not useful let's rip them to not confuse people.


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira <euler@timbira.com> writes:
> Tom Lane escreveu:
>> ISTM your
>> argument can be reduced to "there should be no hidden values ever", but
>> I doubt we're going to buy that.

> No, the "hidden values" has their use case (hiding legal values that we don't
> want to expose, for example, true/false, 0/1, yes/no).

Right ... that's exactly what these are, IMO.

            regards, tom lane