On Mon, Mar 6, 2023 at 12:43 AM Pavel Luzanov <p.luza...@postgrespro.ru> wrote:
> Indeed, adding ADMIN to pg_has_role looks logical. The function will show > whether one role can manage another directly or indirectly (via SET ROLE). > FWIW I've finally gotten to publishing my beta version of the Role Graph for PostgreSQL pseudo-extension I'd been talking about: https://github.com/polobo/RoleGraphForPostgreSQL The administration column basically determines all this via a recursive CTE. I'm pondering how to incorporate some of this core material into it now for both cross-validation purposes and ease-of-use. I handle EMPTY explicitly in the Role Graph but as I noted somewhere in my comments, it really shouldn't be possible to leave the database in that state. Do we need to bug Robert on this directly or do you plan to have a go at it? Adding ADMIN will lead to the question of naming other values. It is more > reasonable to have INHERIT instead of USAGE. > And it is not very clear whether (except for backward compatibility) a > separate MEMBER value is needed at all. > There is an appeal to breaking things thoroughly here and removing both MEMBER and USAGE terms while adding ADMIN, SET, INHERIT. However, I am against that. Most everyday usage of this would only likely care about SET and INHERIT even going forward - administration of roles is distinct from how those roles generally behave at runtime. Breaking the later because we improved upon the former doesn't seem defensible. Thus, while adding ADMIN makes sense, keeping MEMBER (a.k.a., SET) and USAGE (a.k.a., INHERIT) is my suggested way forward. I'll be looking over your v3 patch sometime this week, if not today. David J.
