On Apr 9, 2008, at 12:27 PM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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 can't see any need to do this in a script, and in fact I don't think shell scripting supports it. Totally different story for interactive use. Anyone using *nix is likely to be familiar with how job control works in shells and expecting psql to work the same way. We should try and follow the shell standard as much as possible just so that people don't have to re-train themselves.

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 find myself doing this frequently with any long-running command, but currently it's a PITA because I'd doing it at the shell level and firing up a new psql: more work than should be necessary, and psql sometimes gets confused when you resume it from the background in interactive mode (stops echoing characters, though maybe this has been fixed).

(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 might be true. I don't know if we could use ^z anyway; the shell might have different ideas there.

It makes sense if we continue with the shell analogy: the shell prompt
is not any particular task.  Either there is a task running in
foreground (in which case we have no prompt, but we can press C-z to
suspend the current task and get a prompt), or there isn't (in which
case we have a prompt.)

This is nonsense. When you have a shell prompt, you are connected to a
shell that will take a command right now.

You're always connected to the shell, but if you background something in the shell it becomes a stand-alone job that you're not connected to. You could even think of it as every command you run being a job, it's just a question of if you're actually connected to it or not.
--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to