> I'm pretty strongly disinclined to change the meaning of
> is_admin_of_role() in released code. That affects more than this call
> site. When this code was under development, one of the use cases that
> was booted was a user management bot who should be able to run ALTER
> ROLE but should not automatically exercise the privilege of any
> created roles. If we standardize on ROLERECURSE_PRIVS, that use case
> doesn't work any more. You now have to inherit a role's privileges or
> AlterRole() will fail.
This use case makes sense to me.
> One idea could be that non-membership changes to roles continue to
> work as they do today, but membership changes use ROLERECURSE_PRIVS.
> So we'd have is_admin_of_role() and inherits_admin_privs_for_role()
> and be careful to use the right one in each case. This seems a little
> weird, but I'm not sure what would be better.
Attach a patch done like this.
--
Regards,
ChangAo Chen