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

At Thu, 22 Oct 2020 00:34:20 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> 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
> > 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.

Agreed.

> (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.)

Agreed^2.

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

I thought of that scenarios and conclused as the same. Sounds
reasonable.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center