Re: psql: Add role's membership options to the \du+ command - Mailing list pgsql-hackers

From Pavel Luzanov
Subject Re: psql: Add role's membership options to the \du+ command
Date
Msg-id e90e6775-63a0-6400-1a46-5e4a11124d50@postgrespro.ru
Whole thread Raw
In response to Re: psql: Add role's membership options to the \du+ command  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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 by date:

Previous
From: Mikael Kjellström
Date:
Subject: Re: Direct I/O
Next
From: Dmitry Dolgov
Date:
Subject: Re: [RFC] Add jit deform_counter