Re: issue with pg_db_cancel

Greg Sabino Mullane <[email protected]> writes:
> On Thu, May 29, 2025 at 12:52=E2=80=AFPM Rainer Weikusat <rweikusat@cyber=
adapt.com>
> wrote:
>
>> descriptors connecting to any number of different external and internal
>> entites which doesn't want to be blocked waiting for input to become
>> available on any particular file descriptor.
>
>
> Ah, I understand what you mean now.
>
> NB: This is more-or-less for theoretical consideration. As such a change
>> might well break existing code, it would IMHO be very ill advised to
>> do this in a stable driver
>
>
> Well, we could consider putting it behind a flag so the user can choose t=
he
> current or correct behavior as they see fit.

Alternate idea which would probably be easier to implement (eg, only
additions to the existing tests but no changes):

1. Leave pg_db_cancel semantically as-is. Fix the result handling. Split
   the 'send cancel request' part off into a separate function (could be
   called pg_db_request_cancel as slight pun on libpq).

2. Remove the 'query cancelled' state and all code dealing with it as
   this was likely only ever a workaround for the deficient=C2=B9 result
   handling in the existing cancel function.

3. Change handle_old_sync to call pg_db_cancel instead of duplicating
   its implementation.

I'd volunteer to implement this if it were considered acceptable.

=C2=B9 handle_old_async has its own implementation of a synchronous cancel
operation and does PQgetResult in a loop, as required by the libpq
documentation.