Re: Granting control of SUSET gucs to non-superusers
От | Chapman Flack |
---|---|
Тема | Re: Granting control of SUSET gucs to non-superusers |
Дата | |
Msg-id | 608D83BC.7060101@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: Granting control of SUSET gucs to non-superusers (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: Granting control of SUSET gucs to non-superusers
|
Список | pgsql-hackers |
On 05/01/21 12:13, Mark Dilger wrote: > Extra syntax for use by the service provider seems much easier to justify. > > If the service provider can install extra role-aware check_hooks for gucs, > and if the include directive for postgresql.conf can specify a role under > which a postgresql.conf.tenant file is processed, then the tenant can port > their application and their config file and the only things that should break > are those things the provider has intentionally prohibited. Maybe version 0 is where the provider just builds a shared object to go in shared_preload_libraries. The provider has probably already done a bunch of other stuff more challenging than that. The GUC system would have to expose a way for the shared object to chain extra_check_hooks off existing GUCs. An extra_check_hook can check both the value and the role of the caller. The configfile syntax for include-with-a-role would be the only other missing piece. Version 0.5 is maybe where someone contributes code for such a shared object that is somewhat general and configured by a yaml file, or something. (That would probably be easier if an extra_check_hook accepts the usual void *extra context argument that existing GUC hooks don't.) Regards, -Chap
В списке pgsql-hackers по дате отправления: