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

On 23.07.2024 15:53, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov<p(dot)luzanov(at)postgrespro(dot)ru> wrote:
>> Visible but inaccessible objects in system catalogs increase the volume
>> of command output unnecessarily. Why do I need to know the list of all
>> schemas in the database if I only have access to the public schema?
>> The same applies to inaccessible tables, views, functions, etc.
>>
>> Not for safety, but for convenience, it might be worth having a set of views
>> that show only those rows of the system catalog (with *acl column) that
>> the user has access to. Either as the object owner, or through the privileges.
>> Directly or indirectly through role membership.
> So, I wasn't actually aware that anyone had a big problem in this
> area. I thought that most of the junk you might see in \d<whatever>
> output would be hidden either because the objects you don't care about
> are not in your search_path or because they are system objects. I
> agree that doesn't help with schemas, but most people don't have a
> huge number of schemas, and even if you do, you don't necessarily need
> to look at the list all that frequently.

Maybe. But it would be better not to see unnecessary objects in the
system catalogs. Especially for GUI tools. Back to the subject.

> So, personally, if I were going to work on a redesign in this area, I
> would look into making \du <username> work like \d <tablename>. That
> is, it would tell you every single thing there is to know about a
> user. Role attributes. Roles in which this role has membership. Roles
> that are a member of this row. Objects of all sorts this object owns.
> Permissions this role has on objects of all sorts. Role settings. All
> of it in SQL-ish format like we do with the footer when you run \d.
> Then I would make \du work like \d: a minimal amount of basic
> information about every role in the list, like whether it's a
> superuser and whether they can log in.

Yes, I still like this idea.
A little later I will try to make a patch in this direction.

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