Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I would be glad to see USERLIMIT gone, even though I wrote it. However,
> I feel we are removing user's ability of non-super users to turn logging
> on and off easily without really having thought through a mechanism to
> give them that.
I think that is a very weak argument. Remember that the discussion
started because setting these variables via ALTER USER fails to work.
Why is that of less concern than the fact that unprivileged users won't
be able to increase the log level by themselves? I think it's pretty
debatable whether the current behavior is a feature at all, rather than
a security hole.
> I just don't see people creating secuirty definer
> functions easily to do this
create or replace function enable_logging(bool) returns void as $$
begin
if $1 then
set log_statement = 'all';
else
set log_statement = 'ddl';
end if;
return;
end$$ language plpgsql security definer;
revoke execute on function enable_logging(bool) from public;
grant execute on function enable_logging(bool) to joe_user;
(My, that was hard ...)
You seem to be supposing that anyone who needs this will be needing a
bug-for-bug equivalent to the existing USERLIMIT behavior. I don't
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.
Arguably, this approach is better than directly calling the SET commands
anyway, because it insulates the application code from the changing
details of the specific GUC variables. Need I remind you that any app
that directly issues "SET log_statement" is going to be broken by 8.0?
In 7.4 this variable took "on" and "off", now it does not. The argument
of preserving backwards-compatible behavior looks a bit funny beside
that reality.
regards, tom lane
