Re: [PATCH] New predefined role pg_manage_extensions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] New predefined role pg_manage_extensions
Date
Msg-id CA+TgmoZ_JzehEBLPecSnHfavDvwd5beDWXSnyV7GZxUjXqhYZQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] New predefined role pg_manage_extensions  (Michael Banck <mbanck@gmx.net>)
Responses Re: [PATCH] New predefined role pg_manage_extensions
List 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 by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Add Postgres module info
Next
From: Tom Lane
Date:
Subject: Re: making EXPLAIN extensible