Re: Wrong varnullingrels for MERGE into a trigger-updatable view

On Fri, 13 Nov 2026 at 13:13, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
>
> I found another “wrong varnullingrels” error involving MERGE into a
> trigger-updatable view:

Ah, yes, well spotted.

The test case can a simplified a little:

DROP TABLE IF EXISTS src, tgt CASCADE;
CREATE TABLE src(a int, b int);
CREATE TABLE tgt(a int, b int);
CREATE VIEW tgt_v AS SELECT * FROM tgt;

CREATE OR REPLACE FUNCTION tgt_v_ins_fn() RETURNS trigger
LANGUAGE plpgsql AS $$ BEGIN RETURN new; END $$;

CREATE TRIGGER tgt_v_ins_trig INSTEAD OF INSERT ON tgt_v
FOR EACH ROW EXECUTE FUNCTION tgt_v_ins_fn();

MERGE INTO tgt_v t
USING (src s JOIN src s2 ON s2.b = s.b) ON t.b = s.b AND t.b = 0
WHEN MATCHED AND t.b = 0 THEN DO NOTHING
WHEN NOT MATCHED THEN INSERT VALUES (s.a, s.b);

> The attached patch instead refactors the existing handling. It first
> collects all relation RT indexes on nullable sides of the MERGE join:
>
> - source relids for a left join;
> - the target relid for a right join;
> - both for a full join.
>
> It then uses that set to mark Vars in the query target list, MERGE
> action expressions, and RETURNING list. For left and full joins, it
> also marks the copy of the merge join condition evaluated above the
> join for NOT MATCHED BY SOURCE processing. The original condition in
> the JoinExpr remains unchanged.

That sounds reasonable.

Release freeze for v19 is getting near, so rather than rushing to fit
this in, I'll leave it until next week, when the freeze on the v19
branch is over.

Regards,
Dean