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.