| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, thommy <der(dot)thommy(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #5656: parameter 'client_min_messages' accept values not listed in enumvals |
| Date: | 2010-09-14 18:57:00 |
| Message-ID: | 10365.1284490620@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Euler Taveira de Oliveira | 2010-09-14 22:39:24 | Re: BUG #5656: parameter 'client_min_messages' accept values not listed in enumvals |
| Previous Message | Euler Taveira de Oliveira | 2010-09-14 18:47:15 | Re: BUG #5656: parameter 'client_min_messages' accept values not listed in enumvals |