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 по дате отправления: