Re: Per-database and per-user GUC settings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Per-database and per-user GUC settings
Date
Msg-id 23467.1012405270@sss.pgh.pa.us
Whole thread Raw
In response to Re: Per-database and per-user GUC settings  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: Per-database and per-user GUC settings  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> Superusers can also add SUSET records to their per-user settings.  I'm
>> currently unsure about whether to allow superusers to add SUSET settings
>> to the per-database settings, because it would mean that the database
>> session would behave differently depending on what user invokes it.

> Imho if the dba adds SUSET's to the per-database settings it should be
> set regardless of the user's privs. (Set with elevated rights)

Yes, it would seem to make more sense to verify the privilege level of
the GUC variables during the SET/ALTER command, and then execute them
more-or-less unconditionally during actual startup. During the SET/ALTER
command you know who is trying to insert the value, and you can let
superusers and db owners do more than average users.  But once the
variable has been successfully inserted, it should apply to everyone.

Example application: suppose we had a SUSET-level variable that controls
priority level of a backend (which we don't, but it makes a good example
case here).  The superuser should be able to set this variable in the
per-user settings of a particular user; the user should then be unable
to change it himself.  Note this is a different case from Andreas'
example of a per-database setting, but I agree with his example too.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: inline is not ANSI C
Next
From: Tom Lane
Date:
Subject: Re: Syscaches should store negative entries, too