On Tue, Jun 24, 2025 at 3:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Now, if the PHV matched something that was already in the
> outer subplan's tlist (recall it only needs to match by phid)
> then we're safe, because that copy would have gotten fixed up
> during extract_lateral_references. But in this example that
> doesn't happen, probably because the PHV contains no Vars
> so it doesn't get put into any baserel's reltarget.
I think the reason the PHV isn't already included in the outer
subplan's tlist is that it's supposed to be evaluated at (7 8), while
the outer rel includes only (7). If the planner chooses a join order
where (7 8) are joined first, the PHV would appear in that join rel's
tlist -- but that's not the case here.
> I'm still trying to wrap my head around whether there are any
> related failure modes in released branches. Steps 1-3 certainly
> have been happening just like that for a long time, so that there
> can be a PHV with an unexpanded SubLink floating around the
> outer query level's data structures. Is the a16ef313f2 code
> really the only way that that version of the PHV can make its way
> into the emitted plan tree? Maybe, but I'm far from convinced.
Prior to a16ef313f, have_dangerous_phv() ensures that we don't choose
a join order where the outer rel includes only (7). Instead, the
planner will always join (7 8) first, allowing the well-preprocessed
PHVs to be included in the tlist of that join rel. The unpreprocessed
PHVs in NestLoop.nestParams don't cause problems because they can
always be replaced with OUTER_VAR vars by setrefs.c. So it seems to
me that we're good in released branches, but I could be wrong.
Thanks
Richard
