Re: Mop-up around psql's \connect behavior

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Wed, 21 Oct 2020 18:59:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
>> ... What I propose
>> is to complain if we have no o_conn *and* we are asked to re-use
>> parameters from it. Otherwise, it's fine.

> The reason I haven't complain about this is I don't reconnect by \c
> after involuntary disconnection. (That is, C-d then psql again:p)

Yeah, me too.

> But once it got on my mind, it might be strange that just \c or \c
> -reuse-previous=y doesn't reconnect a broken session. It might be
> better we reuse the previous connection parameter even if the
> connection has been lost, but this would be another issue.

I did actually look into saving the active connection's PQconninfo
immediately at connection establishment and then referring to it in any
subsequent \connect. Then things could work the same even if the original
connection had failed meanwhile. But there are technical details that
make that a lot harder than it seems on the surface --- mainly, that the
way do_connect works now requires that it have a copy of the PQconninfo
data that it can scribble on, and that won't do if we need the saved
PQconninfo to persist when a \connect attempt fails. That could be dealt
with with enough new code, but I didn't think it was worth the trouble.
(Note that we developers face the server-crashed scenario a whole lot more
often than normal people ;-), so we probably overrate how useful it'd be
to be able to reconnect in that case.)

>> * The old-style-syntax code path understands that it should re-use
>> the old password (if any) when the user, host, and port settings
>> haven't changed. The connstring code path was too lazy to make
>> that work, but now that we're deconstructing the connstring there's
>> very little excuse for not having it act the same way.

> +1 (I thought sslmode might affect but that is wrong since cert
> authenticaion cannot be turned off from command line.)

Yeah. That could affect whether the server asks for a password at
all, but you have to really stretch to think of cases where it could
result in needing a *different* password. An example perhaps is
where pg_hba.conf is configured to do, say, LDAP auth on SSL connections
and normal password auth on non-SSL, and the LDAP server has a different
password than what is in pg_authid. But that seems like something nobody
could want. Also notice that unlike the previous code, with my patch
do_connect will always (barring --no-password) give you an opportunity
to interactively supply a password, even if we initially reused an
old password and it didn't work. So it seems like this will cope
even if you do have a setup as wacko as that.

regards, tom lane