Re: BUG #19380: Transition table in AFTER INSERT trigger misses rows from MERGE when used with INSERT in a CTE

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Tue, 20 Jan 2026 at 08:58, PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> In a CTE that inserts rows with both MERGE and INSERT, the transition table
>> will not contain the rows from the MERGE.

> It looks like the problem stems from this code in
> MakeTransitionCaptureState() in commands/trigger.c:
> table = GetAfterTriggersTableData(relid, cmdType);
> where cmdType might be CMD_MERGE.

> The problem is that MERGE really needs to use the same
> AfterTriggersTableData structs as INSERT, UPDATE, and DELETE, so that
> any captured tuples get added to the same tuplestores.

Yeah, I had just come to the same conclusion when I saw your email.
Using CMD_MERGE as the AfterTriggersTableData lookup key could be
correct if MERGE were supposed to have separate transition tables,
but AFAICT from the spec it isn't.

> Attached is a rough patch doing that.

I haven't read this in detail, but it seems like one issue to think
about is whether it's okay to add fields to struct
TransitionCaptureState in released branches? Although it's nominally
an ABI break, I can't think of a reason why any extension would be
manufacturing its own TransitionCaptureState structs rather than
calling MakeTransitionCaptureState(), nor should an extension be
touching the stated-to-be-private tcs_private field. So it seems
like we should be able to get away with it.

> I wonder if it would be possible to get rid of
> ModifyTableState.mt_oc_transition_capture and just have INSERT ... ON
> CONFLICT DO UPDATE use a single TransitionCaptureState in a similar
> way to MERGE? Anyway, that's a separate idea, not relevant to this bug
> fix.

Yeah, that would have to be HEAD-only in any case; we're not going
to change ModifyTableState in released branches.

regards, tom lane