Re: fixing CREATEROLE

On Tue, Nov 29, 2022 at 12:32 AM <walther(at)technowledgy(dot)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.