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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:56:04
Message-ID: CAEZATCXj1xVnMJoNAS+OpnhM76nvzKLuPSEuk4eJ6RzSz4g5=A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 21 Oct 2026 at 22:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> (If this is in fact rare, and it probably is given that the manual
> deprecates RETURNING WITH in rules, then it's likely not worth
> the trouble to try to fix the query representation to keep the
> aliases separate.)

Agreed.

Actually, I don't think that this is a problem with the query
representation. It's a problem with the output text format used in
EXPLAIN. Changing the query representation won't make that problem go
away -- a query like this may end up with a returning list containing
a mix of Var's with different VarReturningType's some of which came
from the triggering query, and some from the rule action, and simply
outputting "alias.colname" isn't enough to distinguish between them. I
think you'd have to output something like "new(tbl.colname)", which
would be different from "new.column" and "tbl.colname",

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message surya poondla 2026-10-21 23:30:06 Re: two small tab-completion patches (ALTER CONSTRAINT, CHECK modifiers)
Previous Message surya poondla 2026-10-21 21:46:00 Re: tablecmds: Deadlock caused by Attach Partition