On 10/29/21, 12:47 PM, "Tom Lane" <t...@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
