Re: Concurrent psql API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Concurrent psql API
Date
Msg-id 22528.1207762077@sss.pgh.pa.us
Whole thread Raw
In response to Re: Concurrent psql API  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Concurrent psql API  (Decibel! <decibel@decibel.org>)
Re: Concurrent psql API  (Shane Ambler <pgsql@Sheeky.Biz>)
List pgsql-hackers
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'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?)

> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Segfault using heap_form_tuple
Next
From: Andrew Chernow
Date:
Subject: Re: [PATCHES] libpq type system 0.9a