> 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
v4-0001-Fix-error-no-possible-grantors.patch
Description: Binary data
