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