Re: psql: Add role's membership options to the \du+ command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, "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-19 15:39:12
Message-ID: 250360.1689781152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I tried this out. It looks good to me, and I like it. Not translating
> the labels seems correct to me.
> +1 for backpatching to 16, given that it's a psql-only change that
> pertains to a backend change that was done in the 16 timeframe.

Agreed. In the interests of moving things along, I'll take point
on getting this committed.

> Regarding the controversy of showing SET for previous versions, I think
> it's clearer if it's shown, because ultimately what the user really
> wants to know is if the role can be SET to; they don't want to have to
> learn from memory in which version they can SET because the column is
> empty and in which version they have to look for the label.

Seems reasonable. I'll go with that interpretation unless there's
pretty quick pushback.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tristan Partin 2023-07-19 15:57:39 Re: Support to define custom wait events for extensions
Previous Message Dmitry Dolgov 2023-07-19 15:18:29 Re: [RFC] Add jit deform_counter