Horton

Re: Improving psql's \password command

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-11T16:04:02Z
Lists: pgsql-hackers 
On 10/29/21, 5:07 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> "Bossart, Nathan" <bossartn@amazon.com> writes:
>> 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 was afraid somebody would say that.  I have looked at it, but AFAICS
> we'd have to duplicate all of sprompt.c and nearly all of pg_get_line.c
> in order to tie it into psql's SIGINT infrastructure, since we wouldn't
> dare enable the signal handler except during the innermost fgets() call,
> and if we did get a signal we'd still need to clean up the terminal echo
> state, so we couldn't just longjmp out of simple_prompt().  The
> cost/benefit ratio of that doesn't look very good.

Hm.  Is it really necessary to duplicate all of sprompt.c and
pg_get_line.c?  Would it be possible to teach the existing functions
how to optionally enable SIGINT handling instead?  I wouldn't mind
trying my hand at this if it seems like a reasonable approach.

Nathan

Commits

  1. pg_receivewal, pg_recvlogical: allow canceling initial password prompt.

  2. Allow psql's other uses of simple_prompt() to be interrupted by ^C.

  3. Provide a variant of simple_prompt() that can be interrupted by ^C.

  4. Make psql's \password default to CURRENT_USER, not PQuser(conn).