BUG #5656: parameter 'client_min_messages' accept values not listed in enumvals

"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