Alvaro Herrera <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
