List of roles Role name | Attributes | Member of -----------+------------------------------------------------------------+----------- admin | Create role | {bob,bob} bob | | {} postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
First 'grant bob to admin' command issued immediately after creating role bob by superuser(grantor=10). Second command issues by admin role and set membership options SET and INHERIT.If we don't ready to display membership options with \du+ may be at least we must group records in 'Member of' column for \du command?
I agree that these views should GROUP BY roleid and use bool_or(*_option) to produce their result.
Ok, I'll try in the next few days. But what presentation format to use?
This is the format I've gone for (more-or-less) in my RoleGraph view (I'll be sharing it publicly in the near future).
bob from grantor (a, s, i) \n
adam from postgres (a, s, i) \n
emily from postgres (empty)
I don't think first-letter mnemonics will be an issue - you need to learn the syntax anyway. And it is already what we do for object grants besides.
Based upon prior comments going for something like the following is undesirable: bob=asi/grantor
So I converted the "/" into "from" and stuck the permissions on the end instead of in the middle (makes reading the "from" fragment cleaner).
To be clear, this is going away from grouping but trades verbosity and deviation from what is done today for better information. If we are going to break this I suppose we might as well break it thoroughly.
