From: Andrei Lepikhov <lepihov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for
Date: Tue, 20 Aug 2024 11:43:57 +0200
Message-ID: <1d65ca34-92d3-47c9-a92b-a6ae0907cdc8@gmail.com> (raw)
In-Reply-To: <7f8bfe01-bc5f-4a93-bcd6-b06e7c24f804@gmail.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: lepihov@gmail.com, tgl@sss.pgh.pa.us, guofenglinux@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for
In-Reply-To: <1d65ca34-92d3-47c9-a92b-a6ae0907cdc8@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox