Re: [PATCH] New predefined role pg_manage_extensions
От | Robert Haas |
---|---|
Тема | Re: [PATCH] New predefined role pg_manage_extensions |
Дата | |
Msg-id | CA+TgmoZ_JzehEBLPecSnHfavDvwd5beDWXSnyV7GZxUjXqhYZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] New predefined role pg_manage_extensions (Michael Banck <mbanck@gmx.net>) |
Ответы |
Re: [PATCH] New predefined role pg_manage_extensions
|
Список | pgsql-hackers |
On Fri, Mar 7, 2025 at 9:37 AM Michael Banck <mbanck@gmx.net> wrote: > Also, I think there is case to be made that a cloud provider (or site > admin) would like to delegate the decision whether users with CREATE > rights on a particular database are allowed to install some extensions > or not. Or rather, assign somebody they believe would make the right > call to do that, by granting pg_manage_extensions. Hypothetically, somebody could want a feature at various levels of granularity. The most fine-grained would be something like: [1] allow user X to install extension Y. Then, more broadly, you could have: [2] allow any user who can install extensions to install extension Y. Or conversely: [3] allow user X to install any extension. This patch implements [3], but you could make an argument for any of the others. My previous proposal amounted to allowing [2] via filesystem hacks, but you could also have a GUC to allow [2], approximately: artifically_trusted_extensions = foo, bar. That would actually allow for [1] as well, because you could apply that GUC via ALTER ROLE .. SET. I'm not saying that's necessarily better than what you're proposing, but I think it's worth taking the time to think through the options carefully. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: