On 10/29/21, 12:47 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> While testing that, I noticed another bit of user-unfriendliness:
> there's no obvious way to get out of it if you realize you are
> setting the wrong user's password. simple_prompt() ignores
> control-C, and when you give up and press return, you'll just
> get the prompt to enter the password again. If at this point
> you have the presence of mind to enter a deliberately different
> string, you'll be out of the woods. If you don't, and just hit
> return again, you will get this response from the backend:
>
> NOTICE: empty string is not a valid password, clearing password
>
> which is just about the worst default behavior I can think of.
> If you're superuser, and you meant to set the password for user1
> but typed user2 instead, you just clobbered user2's password,
> and you have no easy way to undo that.
Well, as of bf6b9e9, "ALTER ROLE nathan PASSWORD ''" is effectively
the same as "ALTER ROLE nathan PASSWORD NULL". I agree about the
user-unfriendliness, but maybe simple_prompt() ignoring control-C is
the root-cause of the user-unfriendliness. I'm not sure that it's
totally unreasonable to expect the password to be cleared if you don't
enter a new one in the prompts.
> A compromise position could be to keep PQuser() as the default
> target role name in the back branches, but back-patch the other
> aspects (the prompt addition and the exit on empty password).
I think it would be okay to back-patch the PQuser() fix. I would
argue that it's clearly a bug because the docs say it uses the current
user.
Nathan
