Re: Concurrent psql API

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Concurrent psql API
Дата
Msg-id 22528.1207762077@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Concurrent psql API  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Concurrent psql API  (Decibel! <decibel@decibel.org>)
Re: Concurrent psql API  (Shane Ambler <pgsql@Sheeky.Biz>)
Список 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 по дате отправления:

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Segfault using heap_form_tuple
Следующее
От: Andrew Chernow
Дата:
Сообщение: Re: [PATCHES] libpq type system 0.9a