Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for
Date: 2024-08-19 19:16:22
Message-ID: 7f8bfe01-bc5f-4a93-bcd6-b06e7c24f804@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 19/8/2024 19:26, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Matthew Clark 2024-08-20 00:45:30 server crash on raspberry pi for large queries
Previous Message Tom Lane 2024-08-19 17:26:50 Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for