| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, rmt(at)lists(dot)postgresql(dot)org, horikyota(dot)ntt(at)gmail(dot)com |
| Subject: | Re: psql: Add role's membership options to the \du+ command |
| Date: | 2023-07-13 16:32:40 |
| Message-ID: | 2904260.1689265960@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> writes:
> On 13.07.2023 18:01, Tom Lane wrote:
>> That does not seem right. Is it impossible for pam.set_option
>> to be false? Even if it is, should this code assume that?
> For versions before 16, including one role to another automatically
> gives possibility to issue SET ROLE.
Right, -ENOCAFFEINE.
> IMO, the only question is whether it is correct to show IMPLICIT and
> SET options in versions where they are not actually present
> in pg_auth_members, but can be determined.
Hmm, that's definitely a judgment call. You could argue that it's
useful and consistent, but also that it's confusing to somebody
who's not familiar with the new terminology. On balance I'd lean
to showing them, but I won't fight hard for that viewpoint.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-07-13 16:36:58 | Re: MERGE ... RETURNING |
| Previous Message | Matthias van de Meent | 2023-07-13 16:28:39 | Re: Potential memory leak in contrib/intarray's g_intbig_compress |