Re: ERROR: too late to create a new PlaceHolderInfo

On Thu, Sep 17, 2026 at 10:14 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> A straightforward fix is to expand join alias Vars in the LATERAL
> subquery in pull_up_simple_union_all, before its rtable gets copied,
> so that all the copies share the same PHVs.

Ugh, this doesn't work if the UNION ALL is nested inside another
LATERAL subquery:

select *
from t t1 left join (t t2 join t t3 on true) j on true,
lateral (select * from ((select j offset 0) union all (select null
offset 0)) s) ss;
ERROR: too late to create a new PlaceHolderInfo

Here the UNION ALL gets pulled up while ss is being pulled up, using
ss's own subroot. At that point its RTE isn't LATERAL, and j belongs
to the outer query anyway, so v1 doesn't expand anything. We could
patch pull_up_simple_subquery the same way, but that makes the fix
more like a band-aid.

> This feels more like a band-aid though. I think the more principled
> fix would be a PHV cache in add_nullingrels_if_needed, so that we
> don't generate identical PHVs with different IDs, like what rv_cache
> does in pullup_replace_vars_callback. But since
> flatten_join_alias_vars is called many times per query level, the
> cache would have to live in PlannerInfo, which seems too invasive to
> back-patch.

I still think the PHV cache is the better approach. Attached v2 does
that: add_nullingrels_if_needed now keeps the PHVs it makes in a new
PlannerInfo field, and reuses one when the same expression is expanded
again. This fixes both queries, no matter where the copies come from,
and it also avoids generating duplicate PHVs for the same alias
elsewhere in the query.

The problem with it is that it breaks ABI and can't be back-patched.
Given that there have been no field reports since v16, maybe we can
fix it on master only?

- Richard