Re: psql: Add role's membership options to the \du+ command
| От | David G. Johnston |
|---|---|
| Тема | Re: psql: Add role's membership options to the \du+ command |
| Дата | |
| Msg-id | CAKFQuwbkywHVFPL6TrJiHFd0KgEvdH0LZTSFxAdK4wzP-u8m-A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: psql: Add role's membership options to the \du+ command (Pavel Luzanov <p.luzanov@postgrespro.ru>) |
| Ответы |
Re: psql: Add role's membership options to the \du+ command
(Pavel Luzanov <p.luzanov@postgrespro.ru>)
Re: psql: Add role's membership options to the \du+ command (Pavel Luzanov <p.luzanov@postgrespro.ru>) |
| Список | pgsql-hackers |
On Tue, Feb 21, 2023 at 2:14 PM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
On 17.02.2023 19:53, David G. Johnston wrote:On Fri, Feb 17, 2023 at 4:02 AM Pavel Luzanov <p.luzanov@postgrespro.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.
В списке pgsql-hackers по дате отправления: