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

On 02.01.2024 22:38, Robert Haas wrote:

> To add to that a bit, I would probably never ask a user to give me the
> output of \du to troubleshoot some issue. I would either ask them for
> pg_dumpall -g output, or I'd ask them to give me the raw contents of
> pg_authid. That's because I know that either of those things are going
> to tell me about ALL the properties of the role, or at least all of
> the properties of the role that are stored in pg_authid, without
> omitting anything that some hacker thought was uninteresting. I don't
> know that \du is going to do that, and I'm not going to want to read
> the code to figure out which cases it thinks are uninteresting,
> *especially* if it behaves differently by version.

\d commands are a convenient way to see the contents of the system
catalogs. Short commands, instead of long SQL queries. Imo, this is their
main purpose.

Interpreting values ('No connection' instead of 0 and so on)
can be useful if the actual values are easy to identify. If there is
doubt whether it will be clear, then it is better to show it as is.
The documentation contains a description of the system catalogs.
It tells you how to interpret the values correctly.

> The counterargument is that if you don't omit anything, the output
> gets very long, which is a problem, because either you go wide, and
> then you get wrapping, or you use multiple-lines, and then if there
> are 500 users the output goes on forever.

This can be mostly solved by using extended mode. Key properties for \du,
all others for \du+. Also \du+ can used with \x.
Of course, the question arises as to which properties are key and
which are not. Here we need to reach a compromise.

> Personally,
> I'd assume that if CONNECTION LIMIT isn't mentioned, it's unlimited.
> But a lot of the other options are less clear. Probably NOSUPERUSER is
> the default and SUPERUSER is the exception, but it's very unclear
> whether LOGIN or NOLOGIN is should be treated as the "normal" case,
> given that the feature encompasses users and groups and non-login
> roles that people access via SET ROLE and things that look like groups
> but are also used as login roles.
>
> And with some of the other options, it's just harder to remember
> whether there's a default and what it is exactly than for other object
> types.

psql provides a handy tool for solving such questions - ECHO_HIDDEN variable.
But it is very important that the query text is easily transformed into
the command output.

Proposed patch tries to implement this approach.

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