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
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 |