From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Final spec on per-database/per-user settings |
Date: | 2002-03-01 01:59:16 |
Message-ID: | Pine.LNX.4.30.0202281816170.691-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-03-01 02:08:28 | More general configurability of session startup actions |
Previous Message | Dann Corbit | 2002-02-28 23:44:54 | Re: Database Caching |