Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery

On Mon, Sep 11, 2023, at 1:28 PM, Richard Guo wrote:
> On Tue, Sep 5, 2023 at 3:23 PM Lepikhov Andrei <lepikhov(at)fastmail(dot)com> wrote:
>> Hi,
>>
>> While designing a CustomScan node, I got stuck into two errors:
>> 1. "failed to find plan for CTE."
>> 2. "failed to find plan for subquery."
>> After a short research, I found commit 3f50b82, which shows the problem's origins - setrefs don't change the varno of custom_scan_tlist and can directly reference CTE or Subquery entry. In the "EXPLAIN VERBOSE" case, the deparsing routine can't find dpns->inner_plan for such an entry.
>
> I was able to reproduce both errors with the help of the query in [1]
> and the extension provided in [2]. It seems that the assumption in the
> case of RTE_SUBQUERY and RTE_CTE in get_name_for_var_field() does not
> always hold:
>
> * the only place we'd see a Var directly referencing a
> * SUBQUERY RTE is in a SubqueryScan plan node
>
> * the only places we'd see a Var directly
> * referencing a CTE RTE are in CteScan or WorkTableScan
> * plan nodes.

I have written the letter with second thoughts, because the logic of building CustomScan target list isn't clear for me. Maybe I just have made a mistake in my code?

>
> But this issue shows that in a CustomScan node we can also see a Var
> directly referencing a SUBQUERY RTE or CTE RTE. (I suspect that it also
> happens with ForeignScan node.)

Maybe, but I couldn't imagine such a situation.

>
> So it seems that we need to assign a proper INNER referent for
> CustomScan node in set_deparse_plan(). I tried 'trick.diff' in [1]
> which uses linitial(dpns->subplans), it fixes the query there but would
> crash the query below.

I see here two different cases. Direct link to a Subquery need rte->subquery, which was nullified due to optimization. The case with reference to CTE is more complex. which subplan of the statement subplans should we refer here? But it is my first glance into this code, maybe someone understand it better.

--
Regards,
Andrei Lepikhov