Re: Concurrent psql patch

On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Gregory Stark <stark(at)enterprisedb(dot)com> 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 decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)