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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, assam258(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 16:17:46
Message-ID: 2207290.1792599466@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 21 Oct 2026 at 15:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could just drop the Asserts and thereby return to the previous
>> behavior. But perhaps your proposal is better. Dean, any thoughts?

> I think just dropping the Asserts is the better solution, because
> showing "Output: n.a" in the EXPLAIN output is likely to lead to
> confusion, since there was no relation with alias "n" in the
> triggering query, and "n" isn't mentioned anywhere else in the EXPLAIN
> output. The user would have to lookup the rule definition to figure
> out what "n" means.

Good point. I'll make it so.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-21 16:38:32 Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan
Previous Message Dean Rasheed 2026-10-21 15:57:48 Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan