On 11/7/19 2:13 PM, Stephen Frost wrote:
>> That doesn't seem like a big objection from here. We could fix it
>> by making a separate privilege bit, but I doubt that it's worth using
>> up one of our limited set of spare bits for.
>
> I do not agree that we should just shift to using default roles instead
> of adding new options to GRANT because of an entirely internal
Am I mis-following the conversation in some way? I'm having trouble
seeing this as a question about a privilege bit, because that leads
straight on to the question of what database object carries the acl
item that grants that bit to a role. An extension isn't yet a database
object until after you create it.
So isn't this more a proposal to add another boolean attribute
to pg_authid, along the lines of rolcreatedb or rolbypassrls?
On the other hand, maybe thinking of it as a privilege bit could
lead somewhere interesting. A not-yet-installed extension isn't
a real database object, but it does have a synthesized existence
as a row in the pg_available_extensions view. Maybe that could
have an acl column, where a privilege (why not just CREATE?) could
be granted to one or more roles. Synthesizing that could rely on
some directive in the control file, or in some separate
extension_creators.conf file that would associate extensions with
roles.
That would avoid using a new bit, avoid adding a pg_authid attribute,
and avoid setting in stone a particular predefined role or two or
a single final meaning of 'trusted'. A site could create a few roles
and edit extension_creators.conf to associate extensions with them.
Maybe that's just a more ad-hoc and GUCless way of circling back
to what the original proposal would be doing with GUCs....
Regards,
-Chap
