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 | e90e6775-63a0-6400-1a46-5e4a11124d50@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: psql: Add role's membership options to the \du+ command (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: