Re: BUG #18238: Cross-partitition MERGE/UPDATE with delete-preventing trigger leads to incorrect memory access

sorry for the noise.
generally I only do regress tests, I should do regress and isolation tests.
your patch is correct, especially ExecCrossPartitionUpdate canSetTag
logic is very intuitive to me.

The test example is so good. Maybe it takes a bit of time for people
to comprehend. (i think)

+-- as above, but blocked by BEFORE DELETE ROW trigger
+BEGIN;
+CREATE FUNCTION trig_fn() RETURNS trigger LANGUAGE plpgsql AS
+ $$ BEGIN RETURN NULL; END; $$;
+CREATE TRIGGER del_trig BEFORE DELETE ON pa_target
+ FOR EACH ROW EXECUTE PROCEDURE trig_fn();
+DO $$
+DECLARE
+ result integer;
+BEGIN
+MERGE INTO pa_target t
+ USING pa_source s
+ ON t.tid = s.sid
+ WHEN MATCHED THEN
+ UPDATE SET tid = tid + 1, balance = balance + delta, val = val ||
' updated by merge'
+ WHEN NOT MATCHED THEN
+ INSERT VALUES (sid, delta, 'inserted by merge');
+GET DIAGNOSTICS result := ROW_COUNT;
+RAISE NOTICE 'ROW_COUNT = %', result;
+END;
+$$;
+SELECT * FROM pa_target ORDER BY tid;
+ROLLBACK;

in
+SELECT * FROM pa_target ORDER BY tid;
I would change to

SELECT pt.*, pg_get_expr(pc.relpartbound, pt.tableoid, TRUE)
FROM pa_target pt
JOIN pg_class pc ON pc.oid = pt.tableoid
ORDER BY val,tid;

that would make the result more understandable, maybe i am over engineering.
Anyway, that's my personal preference.