Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> started because setting these variables via ALTER USER fails to work.
> It fails to work if logging was already on and someone wants to turn it
> off via ALTER USER, and that matches the expected behavior.
Not if a superuser does it; superusers should be allowed to set it
however they want. In current code a superuser can't even set it
that way for himself, let alone for other nonprivileged users.
You seem to define "expected behavior" as "whatever the code does now",
but in point of fact it's got lots of deficiencies.
> Well, you have just made the system less secure by creating that
> function. Why didn't you create a function that has the existing
> behavior of only allowing users to increase the log level?
I repeat my point: I don't think DBAs actually need that. In the
function as illustrated, I gave joe_user (and nobody else) the choice
between 'all' and 'ddl' (and nothing else), where I suppose 'ddl' is the
global default. This is in fact a whole lot *more* secure than the
existing behavior, in the sense that I can constrain what's allowed a
lot more.
If I later decide I want 'mod' as the global default, I can alter the
function to map it that way, and joe_user's application is entirely
unaffected. This is *not* true if I expect joe_user's app to set the
variable directly. He has to go change his app to conform to the new
global default.
>> think so. I think that in the field, people are going to have at most
>> a couple of logging configurations they want to allow users to select,
>> and they will use code not significantly more complex than the above.
> Can you show me the function?
I did.
> You should ask on general where
> we usually do such polls of feature changes?
Where was the poll in which we decided that the logging variables needed
to be secured at all? In 7.3 these variables were all plain USERSET.
regards, tom lane