Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan

From: Henson Choi <assam258(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan
Date: 2026-10-21 23:58:22
Message-ID: CAAAe_zCPdC70FUoDXWXMGHNmteqWdjb-0coOa4sxDqYsZRd6Og@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom, Dean,

> This makes me think it is probably possible to construct scenarios
> where a plan contains both VAR_RETURNING Vars that originated inside
> a rule and some that originated from the calling query, in which
> case using either level's aliases across-the-board would be wrong.

Here is one. With your fragment, the EXPLAIN below prints
"Output: n.a, n.a", although the two columns are the old and new
values (1 and 101). Current master and Ayush's patch print
"Output: n.a, new.a".

CREATE TABLE t (a int, b int);
INSERT INTO t VALUES (1, 10);
CREATE VIEW v AS SELECT * FROM t;
CREATE RULE v_upd AS ON UPDATE TO v DO INSTEAD
UPDATE t SET a = new.a, b = new.b WHERE a = old.a
RETURNING WITH (NEW AS n) n.a, n.b;
EXPLAIN (VERBOSE, COSTS OFF)
UPDATE v SET a = a + 100
RETURNING WITH (OLD AS n) n.a AS old_a, new.a AS new_a;

The calling query names OLD "n" and the rule names NEW "n", so with
the rule's aliases preferred the two sides get the same name.

Best regards,
Henson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-10-22 00:08:57 Re: Row pattern recognition
Previous Message surya poondla 2026-10-21 23:30:06 Re: two small tab-completion patches (ALTER CONSTRAINT, CHECK modifiers)