diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-08-09 11:21:39 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-08-09 11:21:39 -0400 |
| commit | b919a97a6cd204cbd9b77d12c9e60ad59eea04a4 (patch) | |
| tree | ec192f44be4f0ec0057539c30ba3dec587a9c9b9 /src/backend/optimizer/plan/createplan.c | |
| parent | 7da1bdc2c2f17038f2ae1900be90a0d7b5e361e0 (diff) | |
| download | postgresql-b919a97a6cd204cbd9b77d12c9e60ad59eea04a4.tar.gz postgresql-b919a97a6cd204cbd9b77d12c9e60ad59eea04a4.zip | |
Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.
To deparse a reference to a field of a RECORD-type output of a
subquery, EXPLAIN normally digs down into the subquery's plan to try
to discover exactly which anonymous RECORD type is meant. However,
this can fail if the subquery has been optimized out of the plan
altogether on the grounds that no rows could pass the WHERE quals,
which has been possible at least since 3fc6e2d7f. There isn't
anything remaining in the plan tree that would help us, so fall back
to printing the field name as "fN" for the N'th column of the record.
(This will actually be the right thing some of the time, since it
matches the column names we assign to RowExprs.)
In passing, fix a comment typo in create_projection_plan, which
I noticed while experimenting with an alternative fix for this.
Per bug #18576 from Vasya B. Back-patch to all supported branches.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/18576-9feac34e132fea9e@postgresql.org
Diffstat (limited to 'src/backend/optimizer/plan/createplan.c')
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index c6d18ae00f3..28addc1129a 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -2022,7 +2022,7 @@ create_projection_plan(PlannerInfo *root, ProjectionPath *best_path, int flags) * Convert our subpath to a Plan and determine whether we need a Result * node. * - * In most cases where we don't need to project, creation_projection_path + * In most cases where we don't need to project, create_projection_path * will have set dummypp, but not always. First, some createplan.c * routines change the tlists of their nodes. (An example is that * create_merge_append_plan might add resjunk sort columns to a |