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

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Jan 5, 2023 at 11:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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