Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-08-19T19:16:22Z
Lists: pgsql-bugs
On 19/8/2024 19:26, Tom Lane wrote: > Andrei Lepikhov <lepihov@gmail.com> writes: >> On 19/8/2024 18:36, Tom Lane wrote: >>> This seems like it's making assumptions it shouldn't about what >>> CustomScan does. If there's an argument for doing this, it should >>> be added to the adjacent comments. > The main reason I'm being sticky about this is that if we need to > allow CustomScan, then it seems likely that we also need to allow > ForeignScan, and maybe some other things, and then I start to > wonder if we should have any assertion at all about the child > plan type. So I want to actually understand what is the scenario > in which this will happen. I understand your point — the origins of ForeignScan and CustomScan are the same. However, we also have a difference: CustomScan can be executed locally and sometimes may allow volatile functions, CTE, and many other things in the underlying subtree. That's why we can't replay some cases with ForeignScan stuff. But ok, it make sense. I'll try to reproduce the case by employing ForeignScan. -- regards, Andrei Lepikhov
Commits
-
Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.
- b919a97a6cd2 18.0 landed
- 81a12a447753 17.0 landed
- 7408772de563 12.21 landed
- 3ad35d5022c9 13.17 landed
- 120dd033761d 14.14 landed
- 12010f414615 15.9 landed
- 03f679475d9a 16.5 landed
-
Make the upper part of the planner work by generating and comparing Paths.
- 3fc6e2d7f5b6 9.6.0 cited