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

Поиск
Список
Период
Сортировка
От Pavel Luzanov
Тема Re: psql: Add role's membership options to the \du+ command
Дата
Msg-id bb051c99-7f46-77f3-b26e-e0d7ff2c3fe9@postgrespro.ru
обсуждение исходный текст
Ответ на Re: psql: Add role's membership options to the \du+ command  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: psql: Add role's membership options to the \du+ command  (Pavel Luzanov <p.luzanov@postgrespro.ru>)
Список pgsql-hackers
On 08.07.2023 20:07, Tom Lane wrote:
1. I was thinking in terms of dropping the "Member of" column entirely
in \du and \dg.  It doesn't tell you enough, and the output of those
commands is often too wide already.

I understood it that way that the dropping "Member of" column will be done as part of another work for v17. [1]
But I'm ready to do it now.

2. You have describeRoleGrants() set up to localize "ADMIN", "INHERIT",
and "SET".  Since those are SQL keywords, our usual practice is to not
localize them; this'd simplify the code.

The reason is that \du has translatable all attributes of the role, including NOINHERIT.
I decided to make a new command the same way.
But I'm ready to leave them untranslatable, if no objections.

3. Not sure about use of LEFT JOIN in the query.  That will mean we
get a row out even for roles that have no grants, which seems like
clutter.  The LEFT JOINs to r and g are fine, but I suggest changing
the first join to a plain join.

It was David's suggestion:

On 24.06.2023 18:57, David G. Johnston wrote:
On Sat, Jun 24, 2023 at 8:11 AM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
* The new meta-command will not show all roles. It will only show the
roles included in other roles.
To show all roles you need to add an outer join between pg_roles and
pg_auth_members.
But all columns except "role" will be left blank. Is it worth doing this?


I'm inclined to want this.  I would be good when specifying a role to filter upon that all rows that do exist matching that filter end up in the output regardless if they are standalone or not.

Personally, I tend to think that left join is not needed. No memberships - nothing shown.

So, I accepted all three suggestions. I will wait for other opinions and
plan to implement discussed changes within a few days.


1. https://www.postgresql.org/message-id/4133242.1687481416%40sss.pgh.pa.us
-- 
Pavel Luzanov
Postgres Professional: https://postgrespro.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Autogenerate some wait events code and documentation
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)