Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-06-28T18:26:58Z
Lists: pgsql-bugs

Attachments

Alexander Lakhin <exclusion@gmail.com> writes:
> 28.06.2025 00:37, Tom Lane wrote:
>> ... BTW, looking at these two patches again, I wonder if it'd be
>> better to put the hackery for SubLink conversion into
>> identify_current_nestloop_params?  That'd remove the need to argue
>> that we don't have to fix both copies of a nestloop-parameter PHV.

> I've discovered a query which fails with an error after a16ef313f with
> both v2 patches applied:

Thank you!  That demonstrates an unrelated oversight in a16ef313f:
we need to apply replace_nestloop_params() to the expression of a PHV
that is chosen to be a nestloop param.  That's because it could
contain references to Vars/PHVs that will be supplied by some upper
nestloop.

In v3 attached, I moved the SubLink hacking into
identify_current_nestloop_params as suggested above.  But
replace_nestloop_params is local to createplan.c, and anyway we can't
run it until all of the current nestloop's NLPs have been removed from
root->curOuterParams, else it might make invalid replacements.  So
that has to be done in create_nestloop_plan.

I squashed everything into one patch, too.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix some new issues with planning of PlaceHolderVars.

  2. Remove planner's have_dangerous_phv() join-order restriction.