On Tue, Nov 29, 2022 at 12:32 AM <walt...@technowledgy.de> wrote: > > Is there any other argument to be made against ADP? >
These aren't privileges, they are memberships. The pg_default_acl catalog is also per-data while these settings should be present in a catalog which, like pg_authid, is catalog-wide. This latter point, for me, disqualifies the command itself from being used for this purpose. If we'd like to create ALTER DEFAULT MEMBERSHIP (and a corresponding cluster-wide catalog) then maybe the rest of the design would work within that. > > Note, that ADP allows much more than just creating a grant for the > CREATEROLE user, which would be the case if the default GRANT was made > TO the_create_role_user. But it could be made towards *other* users as > well, so you could do something like this: > > CREATE ROLE alice CREATEROLE; > CREATE ROLE bob; > > ALTER DEFAULT PRIVILEGES FOR alice GRANT CREATED ROLE TO bob WITH SET > TRUE, INHERIT FALSE; > What does that accomplish? bob cannot create roles to actually exercise his privilege. > This is much more flexible than role attributes or GUCs. > > The main advantage of GUC over a role attribute is that you can institute layers of defaults according to a given cluster's specific needs. ALTER ROLE SET (pg_db_role_setting - also cluster-wide) also comes into play; maybe alice wants auto-inherit while in db-a but not db-b (this would/will be more convincing if we end up having per-database roles). If we accept that some external configuration knowledge is going to influence the result of executing this command (Tom?) then it seems that all the features a GUC provides are desirable in determining how the final execution context is configured. Which makes sense as this kind of thing is precisely what the GUC subsystem was designed to handle - session context environments related to the user and database presently connected. David J.
