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: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: assam258(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Subject: Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan
Date: 2026-10-21 14:46:56
Message-ID: 2201068.1792594016@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> writes:
> While looking at 1999fe227df, I noticed that the new Assert(refname)
> in get_variable() can be hit through a rule (v v edge case, fuzz testing):

Ah, I wondered if those Asserts were too aggressive.

> The attached patch just keeps the rule's alias in that case, and
> EXPLAIN then shows "Output: n.a". Thoughts?

We could just drop the Asserts and thereby return to the previous
behavior. But perhaps your proposal is better. Dean, any thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rui Zhao 2026-10-21 14:56:06 Re: Allow table AMs to define their own reloptions
Previous Message Fujii Masao 2026-10-21 14:43:13 Re: [PATCH] Report no unpinned buffers as insufficient resources