Re: psql: Add role's membership options to the \du+ command
Pavel Luzanov <p.luzanov@postgrespro.ru>
From: Pavel Luzanov <p.luzanov@postgrespro.ru>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: david.g.johnston@gmail.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com,
david.zhang@highgo.ca, pgsql-hackers@lists.postgresql.org
Date: 2023-04-15T13:16:26Z
Lists: pgsql-hackers
On 14.04.2023 10:28, Kyotaro Horiguchi wrote: > As David-G appears to express concern in upthread, I don't think a > direct Japanese translation from "rolename from rolename" works well, > as the "from" needs accompanying verb. I, as a Japanese speaker, I > prefer a more non-sentence-like notation, similar to David's > suggestion but with slight differences: > > "pg_read_all_stats (grantor: postgres, inherit, set)" In this form, it confuses me that 'postgres' and 'inherit, set' look like a common list. > Come to think of this, I recalled a past discussion in which we > concluded that translating punctuation marks appearing between a > variable number of items within list expressions should be avoided... > > Thus, I'd like to propose to use an ACL-like notation, which doesn't > need translation. > > ..| Mamber of | > ..| pg_read_server_files=ais/horiguti,pg_execute_server_program=/postgres | It's very tempting to do so. But I don't like this approach. Showing membership options as an ACL-like column will be confusing. Even in your example, my first reaction is that pg_execute_server_program is available to public. (As for the general patterns, we can also consider combining three options into one column, like pg_class.reloptions.) So, yet another way to discuss: pg_read_all_stats(inherit,set/horiguti) pg_execute_server_program(empty/postgres) One more point. Grants without any option probably should be prohibited as useless. But this is for a new thread. -- Pavel Luzanov Postgres Professional: https://postgrespro.com
Commits
-
Add psql \drg command to display role grants.
- d65ddaca93f6 17.0 landed
- 0a1d2a7df852 16.0 landed