Re: Concurrent psql API

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Shane Ambler <pgsql(at)Sheeky(dot)Biz>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Concurrent psql API
Date: 2008-04-09 19:17:15
Message-ID: C7E52E69-D211-4F8F-A740-5A29B8E5DBB6@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Apr 9, 2008, at 12:27 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Decibel! 2008-04-09 19:29:34 Re: Allow COPY from STDIN to absorb all input before throwing an error
Previous Message Florian Pflug 2008-04-09 19:17:09 Re: [PATCHES] libpq type system 0.9a

Browse pgsql-patches by date

  From Date Subject
Next Message Shane Ambler 2008-04-09 19:33:16 Re: Concurrent psql API
Previous Message Florian Pflug 2008-04-09 19:17:09 Re: [PATCHES] libpq type system 0.9a