diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-06-20 10:22:52 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-06-20 10:22:52 -0400 |
| commit | 0655c03ef9cc6154b0b209059e758863dcf4e6b0 (patch) | |
| tree | a415b667af2d1fa38dfe1b3a52b1a18edf6d9e5f /src/backend/optimizer/plan/setrefs.c | |
| parent | 596114164699bbe184969df374fd6a1d8a93a57c (diff) | |
| download | postgresql-0655c03ef9cc6154b0b209059e758863dcf4e6b0.tar.gz postgresql-0655c03ef9cc6154b0b209059e758863dcf4e6b0.zip | |
Centralize fixups for mismatched nullingrels in nestloop params.
It turns out that the fixes we applied in commits bfd332b3f
and 63e4f13d2 were not nearly enough to solve the problem.
We'd focused narrowly on subquery RTEs with lateral references,
but lateral references can occur in several other RTE kinds
such as function RTEs. Putting the same hack into half a dozen
code paths seems quite unattractive. Hence, revert the code changes
(but not the test cases) from those commits and instead solve it
centrally in identify_current_nestloop_params(), as Richard proposed
originally. This is a bit annoying because it could mask erroneous
nullingrels in nestloop params that are generated from non-LATERAL
parameterized paths; but on balance I don't see a better way.
Maybe at some future time we'll be motivated to find a more rigorous
approach to nestloop params, but that's not happening for beta2.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/CAMbWs48Jcw-NvnxT23WiHP324wG44DvzcH1j4hc0Zn+3sR9cfg@mail.gmail.com
Diffstat (limited to 'src/backend/optimizer/plan/setrefs.c')
| -rw-r--r-- | src/backend/optimizer/plan/setrefs.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index ec5552327fb..c63758cb2b7 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -2289,11 +2289,11 @@ set_join_references(PlannerInfo *root, Join *join, int rtoffset) * the outer-join level at which they are used, Vars seen in the * NestLoopParam expression may have nullingrels that are just a * subset of those in the Vars actually available from the outer - * side. Lateral references can create the same situation, as - * explained in the comments for process_subquery_nestloop_params - * and paraminfo_get_equal_hashops. Not checking this exactly is - * a bit grotty, but the work needed to make things match up - * perfectly seems well out of proportion to the value. + * side. (Lateral references can also cause this, as explained in + * the comments for identify_current_nestloop_params.) Not + * checking this exactly is a bit grotty, but the work needed to + * make things match up perfectly seems well out of proportion to + * the value. */ nlp->paramval = (Var *) fix_upper_expr(root, (Node *) nlp->paramval, |