Re: ERROR: too late to create a new PlaceHolderInfo

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ERROR: too late to create a new PlaceHolderInfo
Date: 2026-09-17 14:07:45
Message-ID: 638780.1789654065@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
>> 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 agree with that sounding more principled, but I wonder if we should
think bigger than just tweaking add_nullingrels_if_needed: if we're
desirous of de-duplicating PHVs, why not do that across the board,
for every place that makes PHVs? So we'd mechanize this in
make_placeholder_expr's assignment of phid rather than somewhere else.

> 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?

Maybe. In the past, when we needed a new struct field, we've sometimes
decided that adding it at the end of the struct in the back branches
would be adequately ABI-compatible. I think we might be able to get
away with that here too, although I'm a bit worried whether any
extensions might be doing makeNode(PlannerInfo).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2026-09-17 14:09:59 Re: JSON_TABLE: table => column ON ERROR propagation
Previous Message Ayush Tiwari 2026-09-17 13:42:33 Re: pgoutput: schema cache cleanup after streamed 2PC