On 28.01.2024 22:51, Pavel Luzanov wrote:
On 23.01.2024 04:18, Tom Lane wrote:
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At best, that's going to be confusing.
Can you get the same result without changing pg_roles?
Hm. I'm not sure if this is possible.
Probably there is a solution without changing pg_roles.
The \du command can execute different queries for superusers and other roles.
For superusers, the query is based on pg_authid, for other roles on pg_roles.
So superusers will see the 'Password?' column and the rest won't see him.
In this approach, the \du command will be able to work the same way for older
versions.
Is it worth going this way?
On 23.01.2024 05:22, David G. Johnston wrote:
> At present it seems like a createrole permissioned user is unable
> to determine whether a given role has a password or not even in the case
> when that role would be allowed to alter a role they've created to set or
> remove said password. Keeping with the changes made in v16 it does seem
> worthwhile modifying pg_roles to be sensitive to the role querying the view
> having both createrole and admin membership on the role being displayed.
> With now three possible outcomes: NULL if no password is in use, *********
> if a password is in use and the user has the ability to alter role, or
> <insufficient privileges> (alt. N/A).
Once again, this id a good point, but changes to pg_roles are required.
And the behavior of \du will be different for older versions.
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com