Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Jan 5, 2023 at 11:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... But if that is the direction
>> we're going to go in, we should probably revise these APIs to make them
>> less odd.  I'm not sure why we'd keep the REG_CANCEL error code at all.

> Ah, OK.  I had the impression from the way the code is laid out with a
> wall between "PostgreSQL" bits and "vendored library" bits that we
> might have some reason to want to keep that callback interface the
> same (ie someone else is using this code and we want to stay in
> sync?), but your reactions are a clue that maybe I imagined a
> requirement that doesn't exist.

The rcancelrequested API is something that I devised out of whole cloth
awhile ago.  It's not in Tcl's copy of the code, which AFAIK is the
only other project using this regex engine.  I do still have vague
hopes of someday seeing the engine as a standalone project, which is
why I'd prefer to keep a bright line between the engine and Postgres.
But there's no very strong reason to think that any hypothetical future
external users who need a cancel API would want this API as opposed to
one that requires exit() or longjmp() to get out of the engine.  So if
we're changing the way we use it, I think it's perfectly reasonable to
redesign that API to make it simpler and less of an impedance mismatch.

			regards, tom lane