Re: Per-database and per-user GUC settings

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Per-database and per-user GUC settings
Дата
Msg-id 23467.1012405270@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Per-database and per-user GUC settings  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Ответы Re: Per-database and per-user GUC settings
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: inline is not ANSI C
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Syscaches should store negative entries, too