On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > The example, which you moved here, then attempts to demonstrate this "fact" but gets it wrong. Boss became a member of peon so if you want to demonstrate self-administration of a role's membership in a different group you have to login as boss, not peon. Doing that, and then revoking peon from boss, yields "ERROR: must have admin option on role "peon"".
This doesn't seem to me to be making a constructive argument. I showed an example with certain names demonstrating a certain behavior that I find problematic.
Whether you choose the wording of the original thread:
"This is because we allow 'self administration' of roles, meaning that
they can decide what other roles they are a member of."
> The ability of a role to revoke itself from some other role is just > something we need to accept as being a change that needs to be made,
This example:
rhaas=# create user boss;
CREATE ROLE rhaas=# create user peon; CREATE ROLE rhaas=# grant peon to boss; GRANT ROLE rhaas=# \c - peon You are now connected to database "rhaas" as user "peon". rhaas=> revoke peon from boss; -- i don't like being bossed around! REVOKE ROLE
Fails to demonstrate the boss "can revoke itself from peon" / "boss can decide what other roles they are a member of."
You are logged in as peon when you do the revoke, not boss, so the extent of what "boss" can or cannot do has not been shown.
boss is a member of peon, not the other way around. That the wording "grant peon to boss" makes you think otherwise is unfortunate.
