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?


Reply via email to