I 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.
Actually, even more to the point: while this doesn't expose the contents of a role's password, it does expose whether the role *has* a password to every user in the installation. I doubt that that's okay from a security standpoint. It'd need debate at the least.
Makes sense, more reason to put it within its own patch. 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).
