Re: Add non-blocking version of PQcancel - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add non-blocking version of PQcancel
Date
Msg-id 3457746.1648236890@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add non-blocking version of PQcancel  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [EXTERNAL] Re: Add non-blocking version of PQcancel  (Jelte Fennema <Jelte.Fennema@microsoft.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, that's a fair point, but it's somewhat orthogonal to the one I'm
> making, which is that a non-blocking version of function X might be
> expected to share code or at least functionality with X itself. Having
> something that is named in a way that implies asynchrony without other
> differences but which is actually different in other important ways is
> no good.

Yeah.  We need to choose a name for these new function(s) that is
sufficiently different from "PQcancel" that people won't expect them
to behave exactly the same as that does.  I lack any good ideas about
that, how about you?

>> Yeah, I don't think it's anywhere near fully baked yet.  On the other
>> hand, we do have a couple of weeks left.

> We do?

Um, you did read the psql-release discussion about setting the feature
freeze deadline, no?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Enable SSL library detection via PQsslAttribute
Next
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname