Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes - Mailing list pgsql-hackers

From ocie@paracel.com
Subject Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Date
Msg-id 9804281803.AA00362@dolomite.paracel.com
Whole thread Raw
In response to Revised proposal for libpq and FE/BE protocol changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes  (dg@illustra.com (David Gould))
Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
>
> Here is a revised proposal that takes into account the discussions
> of the last few days.  Any comments?

Just one at the end

[snip]

> 4. The frontend may request cancellation of the current query by sending
> a single byte of OOB (out-of-band) data.  The contents of the data byte
> are irrelevant, since the cancellation will be triggered by the associated
> signal and not by the data itself.  (But we should probably specify that
> the byte be zero, in case we later think of a reason to have different
> kinds of OOB messages.)  There is no specific reply to this message.
> If the backend does cancel a query, the query terminates with an ordinary
> error message indicating that the query was cancelled.

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.

Ocie Mitchell

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes
Next
From: lynch@lscorp.com (Richard Lynch)
Date:
Subject: Re: [QUESTIONS] copy command