Hi,
On Tue, Jun 30, 2026 at 1:35 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> I did think of that, but I was uneasy about copying the trigger's old
> tuple after trigger invocation, in case the trigger scribbled on it
> somehow.
Fair argument. I'm convinced.
> Actually, I think a neater long-term solution would be to move all the
> EPQ rechecking and re-computing of the new tuple out of trigger.c, and
> let the caller deal with it, as we do for the MERGE code
Agreed.
> Yes, that's right. The caller does not initialise context->tmfd at
> all, and ExecUpdatePrologue() doesn't touch it if there are no
> triggers.
That works for me.
> OK, I've added a bunch of tests for those cases. As expected, they
> pass even without the code changes, but it's good to confirm that.
Nice, thank you for adding those.
> > Could we add some context to the error message, e.g., mentioning that
> > this happens after processing the BEFORE UPDATE row triggers? That
> > would make it easier to distinguish from the other similar ones.
>
> I'm pretty sure this is a can't-happen error condition, but OK.
Thanks.
Sorry for the late response. I took a look at the v2 patch, tested it
locally, and it looks good to me. I think we should backpatch this fix
down to PG18 (commit 80feb727c86).
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
