Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?
cca5507 <cca5507@qq.com>
From: cca5507 <cca5507@qq.com>
To: Robert Haas <robertmhaas@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>
Cc: preTham <prezza672@gmail.com>, Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-29T08:46:05Z
Lists: pgsql-hackers
Attachments
- v4-0001-Fix-error-no-possible-grantors.patch (application/octet-stream) patch v4-0001
> 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 cited