Re: Concurrent psql API - Mailing list pgsql-hackers

On Apr 9, 2008, at 12:27 PM, 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 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  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828