Re: 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(dot)thommy(at)gmx(dot)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(dot)thommy(at)gmx(dot)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(dot)thommy(at)gmx(dot)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(dot)thommy(at)gmx(dot)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(at)momjian(dot)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(at)timbira(dot)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(at)timbira(dot)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