Chapman Flack <c...@anastigmatix.net> writes: > So isn't this more a proposal to add another boolean attribute > to pg_authid, along the lines of rolcreatedb or rolbypassrls?
I think we've mostly concluded that default roles are superior to pg_authid attributes. The latter are legacy things rather than a model to keep extending. > 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. Meh ... that seems like building a whole new set of infrastructure to solve something that we already have a couple of good models for (i.e., default roles and object-based permissions). I really doubt it's worth the trouble to do that. Although upthread I mentioned the possibility of a database admin editing extension control files, I think most people would consider that to be a truly last resort; you generally want those files to remain as-distributed. The alternative of a new config file is slightly less unmaintainable, but only slightly. There'd be no way to update it from inside the database, short of writing a lot of new infrastructure comparable to ALTER SYSTEM, and surely we don't want to do that. > Maybe that's just a more ad-hoc and GUCless way of circling back > to what the original proposal would be doing with GUCs.... Yeah, I think if we really need per-extension configurability of this, we're going to end up with a GUC. It's just not worth the trouble to build another mechanism that would support such a need. But I'm currently taking the position that we don't need to support that. regards, tom lane