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

On Tue, Feb 21, 2023 at 2:14 PM Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
wrote:

> 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?
>
>
This is the format I've gone for (more-or-less) in my RoleGraph view (I'll
be sharing it publicly in the near future).

bob from grantor (a, s, i) \n
adam from postgres (a, s, i) \n
emily from postgres (empty)
I don't think first-letter mnemonics will be an issue - you need to learn
the syntax anyway. And it is already what we do for object grants besides.

Based upon prior comments going for something like the following is
undesirable: bob=asi/grantor

So I converted the "/" into "from" and stuck the permissions on the end
instead of in the middle (makes reading the "from" fragment cleaner).

To be clear, this is going away from grouping but trades verbosity and
deviation from what is done today for better information. If we are going
to break this I suppose we might as well break it thoroughly.

>
> 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.
>
>
I think that should probably have ADMIN as one of the options as well.
Also curious what it reports for an empty membership.

David J.