From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: I am done |
Date: | 2002-09-05 13:12:41 |
Message-ID: | 28520.1031231561@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> Since the flawed code is now in beta, it will need to be fixed. Do people
> like the above solution or should I just revert to having a seperate
> function for each GUC variable affected?
I do not see a good reason why "fatal" and "off" shouldn't be allowed
values for all three message variables. If we just did that, then you'd
be back to sharable code.
BTW, is it a good idea for server_min_messages and
log_min_error_statement to be PGC_USERSET? I could see an argument that
they should be PGC_SIGHUP, ie, settable only by the admin. As it is,
any user can hide his activity from the logs. OTOH, in the past we've
allowed anyone to change the debug level, and there haven't been
complaints about it.
There's some value in being able to kick the log level up a notch for
a specific session, but knocking it down from the admin's default could
be considered a bad thing. I suppose we could invent a PGC_SIGHUP
"min_server_min_messages" variable that sets a minimum value below which
the user can't set server_min_messages. Does that seem like a good
idea, or overkill?
A compromise position would be to make these two variables PG_SUSET,
ie settable per-session but only if you're superuser.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-09-05 13:15:06 | Re: Inheritance |
Previous Message | Vince Vielhaber | 2002-09-05 12:19:10 | Re: beta1 packaged |