Re: [PATCH] immediately kill psql process if server is not running.

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> Yes, it's true that if the connection breaks, the client may not notice
> that until the next command. But why would we want to kill psql in that
> case? How does that improve the user experience?

> If you're in an interactive session (which is where this matters), and
> you're not running any commands, you're most likely not paying any
> attention to it. So if psql terminates, you won't notice that either. It
> doesn't change anything.

Yeah, I concur that this isn't an improvement. In addition to the
points Tomas raises, consider the possibility that you're typing into
a psql session and not watching closely, and the patch causes psql
to quit asynchronously. Now you are typing at a shell prompt.
If you still aren't watching and hit return, unpleasant results
might ensue.

Perhaps there's something that we could do here, but I'm not sure
what would be a safe behavioral change. We've generally avoided
allowing psql to take actions asynchronously --- as an example,
it doesn't report NOTIFY or NOTICE events during user command input,
even though they might be quite old by the time they do get reported.

One idea that seems like it could be safe is to change the prompt,
so that your experience could be like

postgres=# SELECT foo, bar, baz, <enter>
<DEAD!>-# (uh-oh)

This only helps for people who are entering multi-line SQL, but
perhaps the most aggravating form of this is where you spend awhile
crafting a long command only to see it fail. On the other hand,
as Tomas says, up-arrow and retry works regardless of command
length. So maybe it's not worth the trouble.

Anyway, I'm inclined to close this CF entry as returned-with-feedback.
Perhaps there's something we can do here, but the current patch feels
like a dead end.

regards, tom lane