Re: Things I don't like about \du's "Attributes" column

Another approach based on early suggestions.

The Attributes column includes only the enabled logical attributes.
Regardless of whether the attribute is enabled by default or not.
This changes the current behavior, but makes it clearer: everything
that is enabled is displayed. This principle is easy to maintain in
subsequent versions, even if there is a desire to change the default
value for any attribute. In addition, the issue with the 'LOGIN' attribute
is being resolved, the default value of which depends on the command
(CREATE ROLE or CREATE USER).

The attribute names correspond to the keywords of the CREATE ROLE command.
The attributes are listed in the same order as in the documentation.
(I think that the LOGIN attribute should be moved to the first place,
both in the documentation and in the command.)

The "Connection limit" and "Valid until" attributes are placed in separate columns.
The "Password?" column has been added.

Sample output.

Patch v3:
=# \du
List of roles
Role name | Attributes | Password? | Valid until | Connection limit
-----------+-------------------------------------------------------------------+-----------+------------------------+------------------
admin | INHERIT | no | | -1
alice | SUPERUSER LOGIN | yes | infinity | 5
bob | CREATEDB INHERIT LOGIN REPLICATION BYPASSRLS | no | 2022-01-01 00:00:00+03 | -1
charlie | CREATEROLE INHERIT LOGIN | yes | | 0
postgres | SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN REPLICATION BYPASSRLS | no | | -1
(5 rows)

The output of the command is long. But there are other commands of
comparable length: \dApS, \dfS, \doS.

Small modification with newline separator for Attributes column:

Patch v3 with newlines:
=# \du
List of roles
Role name | Attributes | Password? | Valid until | Connection limit
-----------+-------------+-----------+------------------------+------------------
admin | INHERIT | no | | -1
alice | SUPERUSER +| yes | infinity | 5
| LOGIN | | |
bob | CREATEDB +| no | 2022-01-01 00:00:00+03 | -1
| INHERIT +| | |
| LOGIN +| | |
| REPLICATION+| | |
| BYPASSRLS | | |
charlie | CREATEROLE +| yes | | 0
| INHERIT +| | |
| LOGIN | | |
postgres | SUPERUSER +| no | | -1
| CREATEDB +| | |
| CREATEROLE +| | |
| INHERIT +| | |
| LOGIN +| | |
| REPLICATION+| | |
| BYPASSRLS | | |
(5 rows)

For comparison, here's what it looks like now:

master:
=# \du
List of roles
Role name | Attributes
-----------+------------------------------------------------------------
admin | Cannot login
alice | Superuser, No inheritance +
| 5 connections +
| Password valid until infinity
bob | Create DB, Replication, Bypass RLS +
| Password valid until 2022-01-01 00:00:00+03
charlie | Create role +
| No connections
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS

From my point of view, any of the proposed alternatives is better than what we have now.
But for moving forward we need to choose some approach.

I will be glad of any opinions.

--
Pavel Luzanov
Postgres Professional:https://postgrespro.com