On 23.07.2024 15:53, Robert Haas wrote:
On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov<p.luza...@postgrespro.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

Reply via email to