Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Date: 1998-04-29 14:28:14
Message-ID: 8596.893860094@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
ocie(at)paracel(dot)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

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 1998-04-29 14:35:26
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Previous:From: Thomas G. LockhartDate: 1998-04-29 13:59:29
Subject: Re: [INTERFACES] Access'97 and ODBC

pgsql-interfaces by date

Next:From: Jose' Soares Da SilvaDate: 1998-04-29 14:31:23
Subject: jdbc vs. odbc performance
Previous:From: Thomas G. LockhartDate: 1998-04-29 13:59:29
Subject: Re: [INTERFACES] Access'97 and ODBC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group