Re: Improving psql's \password command

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improving psql's \password command
Date: 2021-11-20 23:25:43
Message-ID: 7E82AB1D-5D14-458F-8AD3-FFB71B7FAD67@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/20/21, 1:58 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Bossart, Nathan" <bossartn(at)amazon(dot)com> writes:
>> I did find some missing control-C handling in
>> pg_receivewal/pg_recvlogical, though. Attached is a patch for those.
>
> Meh ... I'm inclined to fix those programs by just moving their pqsignal
> calls down to after their initial GetConnection calls, as attached.
> This'd be simple enough to back-patch, for one thing.
>
> It could be argued that this doesn't provide a nice experience if
> (a) somebody changes your password mid-run and (b) you actually
> need to make a new connection for some reason and (c) you want
> to give up at that point instead of putting in the new password.
> But I doubt it's worth so much extra complication to address that
> edge case. We've had about zero field complaints about the existing
> behavior in those programs, so the cost/benefit ratio seems poor.

Yeah, I was looking for a way to simplify this, too. Your approach
seems reasonable enough to me.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-11-21 01:28:25 Re: logical decoding/replication: new functions pg_ls_logicaldir and pg_ls_replslotdir
Previous Message Andrew Dunstan 2021-11-20 22:58:07 Re: Test::More version