Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Shane Ambler wrote:
>>> So I am thinking something like C-z that will allow you to switch out of
>>> a task that is waiting for results without having to stop it with C-c.
>
>> I agree -- we would need to have a mode on which it is "not on any
>> connection", to which we could switch on C-z. If all connections are
>> busy, there's no way to create a new one otherwise.
>
> That would work okay for interactive use and not at all for scripts,
> which makes it kind of a nonstarter. I'm far from convinced that the
> case must be handled anyway. If you fat-finger a SQL command the
> consequences are likely to be far worse than having to wait a bit,
> so why is it so critical to be able to recover from a typo in a \join
> argument?
I can see that a non-connected prompt would interfere with a script but
I would think that a prompt should always be linked to a connection. It
may work to get an un-connected prompt made available from C-z which
could be limited to only allow new connections or \join commands which
would also be limited to interactive input.
My first thoughts where that C-z would either drop back to the previous
connection or create a new connection either based on the initial login
or the connection you are C-z'ing out of. This would be the tricky
decider though which may make a limited prompt viable.
C-z input detection may also be limited to the wait for query response
loop so that it is only available if the current connection is without a
prompt.
I do think it is useful for more than typo's in the \join command. What
about a slip where you forget to \g& the command. Or you start a query
that seems to be taking too long, background it and look into what is
happening. This would be more helpful to those that ssh into a machine
then run psql from there.
> (I'm also unconvinced that there won't be severe implementation
> difficulties in supporting a control-Z-like interrupt --- we don't have
> any terminal signals left to use AFAIK. And what about Windows?)
That may be so and could be the decider over whether this can be added
or not.
Unless Windows steals the input before psql gets it I don't see there
will be a problem there. Windows may be a factor in deciding which key
to use for this command if it is to be uniform across platforms.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
