On Thu, 5 Sep 2002, Tom Lane wrote:
> Gavin Sherry <swm@linuxworld.com.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.
This was one of my other suggestions: does it matter if people can set
client_min_messages to, say, PANIC -- since they wont get it anyway.
> 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?
I think it would be important to implement it this way. I'm surprised this
hasn't come up before. Still, it'd be a 7.4 item.
>
> A compromise position would be to make these two variables PG_SUSET,
> ie settable per-session but only if you're superuser.
Sounds like a reasonably compromise. I cannot think of a reason why
people would be setting server_min_messages per session in
production. Perhaps this should be changed for 7.3?
>
> regards, tom lane
>
Gavin
