But to try to apply that concept
here means that we suppose the user knows whether the default is
INHERIT or NOINHERIT, whether the default is BYPASSRLS or NOBYPASSRLS,
etc. And I'm just a little bit skeptical of that assumption. Perhaps
it's just that I've spent less time doing user management than table
administration and so I'm the only one who finds this fuzzier than
some other kinds of SQL objects, but I'm not sure it's just that.
Roles are pretty weird.

In my consulting experience, it's extremely rare for users to do anything remotely sophisticated with roles (I was always happy just to see apps weren't connecting as a superuser...).

Like you, I view \du and friends as more of a "helping hand" to seeing the state of things, without the expectation that every tiny nuance will always be visible, because I don't think it's practical to do that in psql. While that behavior might surprise some users, the good news is once they start exploring non-default options the behavior becomes self-evident.

Some attributes are arguably important enough to warrant their own column. The most obvious is NOLOGIN, since those roles are generally used for a very different purpose than LOGIN roles. SUPERUSER might be another candidate (though, I much prefer a dedicated "sudo role" than explicit SU on roles).

I'm on the fence when it comes to SQL syntax vs what we have now. What we currenly have is more readable, but off-hand I think the other places we list attributes we do it in SQL syntax. It might be worth changing just for consistency sake.

--
Jim Nasby, Data Architect, Austin TX