Re: Concurrent psql API

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> It strikes me that with these semantics, \cwait is a lot like a thread
>> join operation, so we could call it \join or \j.

> FWIW on POSIX shell there's something similar called "wait".
> http://www.opengroup.org/onlinepubs/009695399/utilities/wait.html
> Perhaps we should define the operator after these semantics -- these
> guys have probably hashed up a good interface. Basically it means we
> would have a "\cwait [n ...]" command meaning "wait for the connection
> 'n' to return".

I was thinking about this some more while out running an errand, and
came to the same conclusion that "\cwait connID" would be a good thing
to have.

> However, the no-operands version of POSIX wait means "wait for all
> commands" instead of "wait for any command". Perhaps we could have
> "\cwait -" as meaning "wait for any command".

That would require prohibiting "-" as a connection ID, but maybe that's
an OK price for acting like a known standard.

Another thought that came to me while driving around is that it seems
bogus to offer a prompt when attached to a connection that can't
actually accept a command right now. I know that psql can get into that
state after a connection dies, but it's still a wart, and not really
something we should design into normal operations. Furthermore, I don't
see the reason for switching to a connection with an active async
command unless you are desiring to wait for that command's result.
So I'm thinking we could unify \S with \cwait. This leads to the
following proposals:

sql-command \g& connID

If connID is idle and not the current connection, issue
sql-command on it, but do *not* switch to that connection.
(There are various possibilities on what to do in the
corner cases where it's busy or the current connection.
If it's busy, we could throw error, or do a forced \join
before issuing the command. If it's the current connection,
my inclination is to treat this exactly like \g, ie wait
for the result.)
Also, if connID is not a known ID, we could automatically
create it as a clone of the current connection; which'd
eliminate the need for explicit \connect& in many cases.
(OTOH that might be too vulnerable to typos.)

\join connID

Switch to connection connID. If it is busy, wait for
command completion and print the result before offering
a new command prompt.

\join (or \join - as per Alvaro)

Wait for any currently busy connection's command to finish,
then \join to it. Error if there is no busy connection.

While there's still a possible use for \D (disconnect) in this
scheme, I'm not sure how interesting it is. In any case disconnecting
the active session is a bogus behavior; you should only be able
to disconnect a non-active, idle one.

regards, tom lane