Re: psql: Add role's membership options to the \du+ command

From: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: David Zhang <david(dot)zhang(at)highgo(dot)ca>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql: Add role's membership options to the \du+ command
Date: 2023-02-21 21:14:34
Message-ID: 94ce7392-fa90-bc1c-4dc2-677161bbff58@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.02.2023 19:53, David G. Johnston wrote:
> On Fri, Feb 17, 2023 at 4:02 AM Pavel Luzanov
> <p(dot)luzanov(at)postgrespro(dot)ru> wrote:
>
>                                    List of roles
>  Role name | Attributes                         | Member of
> -----------+------------------------------------------------------------+-----------
>  admin     | Create
> role                                                | {bob,bob}
>  bob | | {}
>  postgres  | Superuser, Create role, Create DB, Replication,
> Bypass RLS | {}
>
> First 'grant bob to admin' command issued immediately after
> creating role bob by superuser(grantor=10). Second command issues
> by admin role and set membership options SET and INHERIT.
>
> If we don't ready to display membership options with \du+ may be
> at least we must group records in 'Member of' column for \du command?
>
>
> I agree that these views should GROUP BY roleid and use
> bool_or(*_option) to produce their result.

Ok, I'll try in the next few days. But what presentation format to use?

1. bob(admin_option=t inherit_option=t set_option=f) -- it seems very long
2. bob(ai) -- short, but will it be clear?
3. something else?

> Their purpose is to communicate the current effective state to the
> user, not facilitate full inspection of the configuration, possibly to
> aid in issuing GRANT and REVOKE commands.

This can help in issuing GRANT command, but not REVOKE. Revoking a
role's membership is now very similar to revoking privileges. Only the
role that granted membership can revoke that membership. So for REVOKE
you need to know who granted membership, but this information will not
be available after grouping.

> One thing I found, and I plan to bring this up independently once I've
> collected my thoughts, is that pg_has_role() uses the terminology
> "USAGE" and "MEMBER" for "INHERIT" and "SET" respectively.
>
> It's annoying that "member" has been overloaded here.  And the choice
> of USAGE just seems arbitrary (though I haven't researched it) given
> the related syntax.
>
> https://www.postgresql.org/docs/15/functions-info.html
>

I didn't even know this function existed. But I see that it was changed
in 3d14e171 with updated documentation:
https://www.postgresql.org/docs/devel/functions-info.html#FUNCTIONS-INFO-ACCESS
Maybe that's enough.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-02-21 21:30:54 pg_dump: Remove some dead code
Previous Message Andres Freund 2023-02-21 21:12:56 Re: refactoring relation extension and BufferAlloc(), faster COPY