From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Things I don't like about \du's "Attributes" column |
Date: | 2023-06-23 00:50:16 |
Message-ID: | 4133242.1687481416@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nearby I dissed psql's \du command for its incoherent "Attributes"
column [1]. It's too late to think about changing that for v16,
but here's some things I think we should consider for v17:
* It seems weird that some attributes are described in the negative
("Cannot login", "No inheritance"). I realize that this corresponds
to the defaults, so that a user created by CREATE USER with no options
shows nothing in the Attributes column; but I wonder how much that's
worth. As far as "Cannot login" goes, you could argue that the silent
default ought to be for the properties assigned by CREATE ROLE, since
the table describes itself as "List of roles". I'm not dead set on
changing this, but it seems like a topic that deserves a fresh look.
* I do not like the display of rolconnlimit, ie "No connections" or
"%d connection(s)". A person not paying close attention might think
that that means the number of *current* connections the user has.
A minimal fix could be to word it like "No connections allowed" or
"%d connection(s) allowed". But see below.
* I do not like the display of rolvaliduntil, either. Consider
regression=# create user alice password 'secret';
CREATE ROLE
regression=# create user bob valid until 'infinity';
CREATE ROLE
regression=# \du
...
alice |
bob | Password valid until infinity
...
This output claims that bob has an indefinitely-valid password, when in
fact he has no password at all. On the other hand, nothing is said about
alice, who actually *does* have a password valid until infinity. It's
difficult to imagine a more misleading way to present this.
Now, it's hard to do better given that the \du command is examining the
universally-readable pg_roles view, because that doesn't betray any hint
of whether the user has a password or not. I wonder though what is the
rationale for letting unprivileged users see the rolvaliduntil column
but not whether a password exists at all. I suggest that maybe it'd
be okay to change the pg_roles view along the lines of
- '********'::text as rolpassword,
+ case when rolpassword is not null then '********'::text end as rolpassword,
Then we could fix \du to say nothing if rolpassword is null,
and when it isn't, print "Password valid until infinity" whenever
that is the case (ie, rolvaliduntil is null or infinity).
* On a purely presentation level, how did we possibly arrive
at the idea that the connection-limit and valid-until properties
deserve their own lines in the Attributes column while the other
properties are comma-separated? That makes no sense whatsoever,
nor does it look nice in \x display format.
I do grasp the distinction that the other properties are permission
bits while these two aren't, but that doesn't naturally lead to
this formatting. I'd vote for either
(a) each property gets its own line, or
(b) move these two things into separate columns. Some of the
verbiage could then be dropped in favor of the column title.
Right now (b) would lead to an undesirably wide table; but
if we push the "Member of" column out to a different \d command
as discussed in the other thread, maybe it'd be practical.
Anyway, for now I'm just throwing this topic out for discussion.
regards, tom lane
[1] https://www.postgresql.org/message-id/4128935.1687478926%40sss.pgh.pa.us
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2023-06-23 03:38:57 | Re: Skip collecting decoded changes of already-aborted transactions |
Previous Message | Tom Lane | 2023-06-23 00:08:46 | Re: psql: Add role's membership options to the \du+ command |