Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?

> 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.

After thinking more about this case, it seems still work even if we use
ROLERECURSE_PRIVS in is_admin_of_role():

```
postgres=# create role bot createrole;
CREATE ROLE
postgres=# set session authorization bot;
SET
postgres=> create role user1;
CREATE ROLE
postgres=> reset session authorization;
RESET
postgres=# select pg_has_role('bot', 'user1', 'USAGE');
pg_has_role
-------------
f
(1 row)

postgres=# select pg_has_role('bot', 'user1', 'MEMBER');
pg_has_role
-------------
t
(1 row)

postgres=# select pg_has_role('bot', 'user1', 'MEMBER WITH ADMIN OPTION');
pg_has_role
-------------
t
(1 row)

postgres=# select * from pg_auth_members where member = (select oid from pg_authid where rolname = 'bot');
oid | roleid | member | grantor | admin_option | inherit_option | set_option
-------+--------+--------+---------+--------------+----------------+------------
16393 | 16392 | 16391 | 10 | t | f | f
(1 row)

```

The bot doesn't have privs of user1 by default, but is admin of user1. Changing
is_admin_of_role() to use ROLERECURSE_PRIVS only affects the case of indirect
inheritance. Do I miss something?

--
Regards,
ChangAo Chen