Ayush Tiwari <[email protected]> writes:
> On Wed, 21 Oct 2026 at 23:30, Tom Lane <[email protected]> wrote:
>> 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.
>> But we don't have a lot of choice, because that mixing happens in
>> the rewriter and its output format doesn't support recording multiple
>> sets of aliases (or does it? maybe the two sets of Vars will have
>> different varlevelsup?).
> AFAICS no, both come out at varlevelsup 0 with the same varno. E.g.
> if the rule does RETURNING WITH (OLD AS o) o.a, t.b, an outer
> UPDATE v ... RETURNING old.b shows up as o.b in EXPLAIN
Yeah. I am thinking that the VAR_RETURNING representation was done
wrong, and that a superior solution would have involved adding more
dummy RTEs to the rtable and making these Vars reference those by
varno instead of having a separate marker field. Then this problem
would be addressed by existing (I think) logic for merging the rule
and query rtables, and the plan-node aliasname fields probably go away
in favor of RTE indexes for the special RTEs. I'm not volunteering to
rewrite all that, though.
regards, tom lane
