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

I wrote:
> 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.

Actually ... I'd no sooner pushed that patch than I realized that there
*is* an easy, if rather grotty, way to deal with this. We can just not
issue PQfinish on the old/dead connection until we've successfully made
a new one. PQconninfo doesn't care if the connection is in BAD state.

To avoid introducing weird behaviors, we can't keep the logically-dead
connection in pset.db, but introducing a separate variable to hold such
a connection doesn't seem too awful. So that leads me to the attached
patch, which is able to reconnect even if we lost the connection:

regression=# select 1;
?column?
----------
1
(1 row)

-- in another window, stop the server, then:

regression=# select 1;
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

--- now restart the server, and:

!?> \c
You are now connected to database "regression" as user "postgres" via socket in "/tmp" at port "5432".

I would not have wanted to accept a patch that did it the other way,
because it would have been a mess, but this seems small enough to
be worth doing. The only real objection I can see is that it could
hold a server connection open when the user thinks there is none;
but that could only happen in a non-interactive script, and it does
not seem like a big problem in that case. We could alternatively
not stash the "dead" connection after a non-interactive \connect
failure, but I doubt that's better.

regards, tom lane