Re: Concurrent psql API - Mailing list pgsql-hackers

Alvaro Herrera <alvherre@commandprompt.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, issuesql-command on it, but do *not* switch to that connection.(There
arevarious possibilities on what to do in thecorner cases where it's busy or the current connection.If it's busy, we
couldthrow error, or do a forced \joinbefore issuing the command.  If it's the current connection,my inclination is to
treatthis exactly like \g, ie waitfor the result.)Also, if connID is not a known ID, we could automaticallycreate it as
aclone of the current connection; which'deliminate the need for explicit \connect& in many cases.(OTOH that might be
toovulnerable to typos.)
 

\join connID
Switch to connection connID.  If it is busy, wait forcommand completion and print the result before offeringa new
commandprompt.
 

\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