Here is what I have implemented for database and user-specific run-time
configuration settings. Unless there are desired changes, I plan to check
this in tomorrow.
* Syntax
ALTER DATABASE dbname SET variable TO value;
ALTER DATABASE dbname SET variable TO DEFAULT;
ALTER DATABASE dbname RESET variable;
ALTER DATABASE dbname RESET ALL;
And analogously for USER. The second and the third syntax are equivalent.
AFAIK, there's no precedent for this general feature, but the syntax was
sort of extrapolated from a leading vendor's ALTER USER name SET TIME ZONE
statement. (Which, ironically, this patch won't provide, because the time
zone setting is handled separately. I hope to fix this soon.)
* Semantics
Settings are processed just before the session loop starts, thus giving
the intended impression of a SET statement executed manually just before
the session start. This naturally restricts the allowable set of options
to SUSET and USERSET. However, these settings do establish a new default
for the purpose of RESET ALL.
(The truth is, these settings are processed somewhere in the middle of
InitPostgres(). This way we only have to read pg_shadow and pg_database
once per session startup. This keeps the performance impact negligible.)
* Privileges
Users can change their own defaults. Database owners can change the
defaults for the databases they own. Superusers can change anything.
If the executing user is a superuser, he can change SUSET settings. Else
one can only change USERSET settings. This means that superusers can
"force" SUSET settings onto other people who can't unset them.
* Escape hatch
If you severely mess up your settings so that you can't log in you can
still start up a standalone backend. These settings are not processed in
this case.
In the standalone backend we don't even read pg_shadow now, because we set
the uid to 1 in any case. So the reasoning was that if we don't read
pg_shadow, we can't process the user options, and if we don't process the
user options we shouldn't process the database options either.
--
Peter Eisentraut peter_e@gmx.net
