Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org
	(8.8.8/8.7.5) with ESMTP id KAA25295;
	Wed, 29 Apr 1998 10:28:36 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id KAA08598;
	Wed, 29 Apr 1998 10:28:15 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes 
In-reply-to: Your message of Tue, 28 Apr 1998 11:03:09 -0700 (PDT)
	<9804281803.AA00362@dolomite.paracel.com>
Date: Wed, 29 Apr 1998 10:28:14 -0400
Message-ID: <8596.893860094@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

ocie@paracel.com writes:
> You didn't come right out and say it, but are you intending to support
> multiple queries within a connection?  I gather not.  Not that I'm
> suggesting that this be done, as it seems this would complicate the
> user's application and the backend.  With only one possible OOB
> message, you can't tell it which query to cancel.

That was something I asked about a few days ago, and didn't get any
responses suggesting that anyone thought it was likely to happen.

We would need wholesale changes everywhere in the protocol to support
concurrent queries: answers and errors coming back would have to be
tagged to indicate which query they apply to.  The lack of a tag in
the cancel message isn't the controlling factor.

In the current system architecture, much the easiest way to execute
concurrent queries is to open up more than one connection.  There's
nothing that says a frontend process can't fire up multiple backend
processes.  I think this is probably sufficient, because I don't
foresee such a thing becoming really popular anyway.

			regards, tom lane