On Wed, Apr 29, 2026 at 04:46:05PM +0800, cca5507 wrote:
>> 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.
The patch seems to resolve the reported case. I don't like how the new
function is named "has_admin_option_on_role()" because it sounds like it
means the exact same thing as "is_admin_of_role()". IMHO Robert's
suggestion of inherits_admin_privs_of_role() would be better.
I don't have any better ideas for how to solve it, but I also fear for the
day when I have to explain these subtle differences in behavior to a casual
user...
--
nathan
