I'd like to propose that we get rid of GUC's USERLIMIT category and
convert all the variables in it to plain SUSET. In my mind, USERLIMIT
is a failed experiment: it's way too complicated, and it still doesn't
do quite what it was intended to do, because there are times when it
can't check whether you're a superuser.
The only variables that are in the category are log-verbosity-related:
regression=# select name from pg_settings where context = 'userlimit'; name
----------------------------log_durationlog_executor_statslog_min_duration_statementlog_min_error_statementlog_min_messageslog_parser_statslog_planner_statslog_statementlog_statement_stats
(9 rows)
What the USERLIMIT code tries to do is allow non-superusers to
"increase" but not "decrease" the logging verbosity for their sessions
only. (For instance, a non-superuser could turn log_duration on, but
can't turn it off if the DBA has turned it on.) However, the usefulness
of this capability is really pretty debatable. A non-superuser
presumably doesn't have access to the postmaster log file anyhow, so why
does he need to be able to turn up the logging? You could even argue
that being able to flood the logs with stuff the DBA doesn't want is a
mild form of DOS attack.
If we do get rid of USERLIMIT, another benefit accrues: we can assume
that ALTER USER and ALTER DATABASE settings were fully checked when they
were installed, and thereby accept them at session start without any
extra permissions check. This would mean that, for example, a superuser
could use ALTER USER to set these variables on a per-user basis for
non-superusers, and it would actually work. Right now the value is
rechecked as if the setting were being issued by the non-superuser,
and so it may fail.
For more discussion see this thread in pgsql-bugs:
http://archives.postgresql.org/pgsql-bugs/2004-11/msg00101.php
regards, tom lane
