On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > Gregory Stark <[EMAIL PROTECTED]> writes: > >> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered > >> that > >> previously since I'm not accustomed to using \g but it does seem kind of > >> pretty. I normally use ; but I suppose there's nothing wrong with just > >> declaring that asynchronous commands must be issued using \g& rather than > >> use > >> the semicolon to fire them off. > > > > It makes sense to me... but what is the state of the session afterward? > > Should this be combined with switching to another connection? > > It's an interesting idea since you'll inevitably have to switch connections. > If you issue a second query it'll forces the session to wait for the results. > (It doesn't seem like there's any point in keeping a queue of pending queries > per session.) > > However we do still need a command to switch back anyways so there doesn't > seem to be any advantage in combining the two.
I'd thought about this, and the question I came up with was: what connection should we switch to? First thought was to switch back to whatever connection we'd been using before this one, but then you'd quickly have 2 connections tied up... then what? If someone could come up with a logical session to connect to automatically that'd be great. In the meantime, what about allowing \g& accept a connection number to switch to? Also, I'd really love it if we could also do ';&'... I didn't mention it before because I'm assuming it's essentially not possible, but I'd like to be wrong... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
