Message-ID: <1d65ca34-92d3-47c9-a92b-a6ae0907cdc8@gmail.com>
Date: Tue, 20 Aug 2024 11:43:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18576: Using EXPLAIN (VERBOSE) in
 information_schema.element_types returns ERROR: failed to find plan for
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
References: <18576-9feac34e132fea9e@postgresql.org>
 <CAMbWs49gOeyotM7riJ-q_NgLgfA6-3z7DffnR71kSyaHTkh2ig@mail.gmail.com>
 <2336091.1723137115@sss.pgh.pa.us> <2493069.1723149304@sss.pgh.pa.us>
 <CAMbWs4_Au2i+p2MbZ8nNB_QQXrFy65CXNeJL11j2WJbNW18fHQ@mail.gmail.com>
 <2548861.1723174234@sss.pgh.pa.us> <2799439.1723217127@sss.pgh.pa.us>
 <332f0e30-f90a-4e47-b668-b53f649c244f@gmail.com>
 <1385302.1724085401@sss.pgh.pa.us>
 <5e129a8e-5b8d-4a61-9776-59be99a2c14f@gmail.com>
 <1390980.1724088410@sss.pgh.pa.us>
 <7f8bfe01-bc5f-4a93-bcd6-b06e7c24f804@gmail.com>
Content-Language: en-US
In-Reply-To: <7f8bfe01-bc5f-4a93-bcd6-b06e7c24f804@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1d65ca34-92d3-47c9-a92b-a6ae0907cdc8%40gmail.com>
Precedence: bulk

On 19/8/2024 21:16, Andrei Lepikhov wrote:
> 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.
Delving into the intricacies of ForeignScan, I came to the realization 
that implementing a push-down of ROW() expression in FDW is no simple 
feat. It requires a 'deparse' routine and other complex stuff. While 
there have been the attempt [1], it appears to be in a raw state, making 
it challenging to use.
Given that ForeignScan forms a flat target list for foreign scans and 
assembles whole-row expressions locally, it's worth pondering: do we 
really need to limit CustomScan in the same way? If yes, should we add a 
'restrictions' section describing the limitations of the underlying 
subtree's target list to the documentation?

[1] 
https://www.postgresql.org/message-id/2253e9091b300d868d524c0943fa8796@postgrespro.ru

-- 
regards, Andrei Lepikhov