| 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
| 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) |