From: Tom Lane <tgl@sss.pgh.pa.us>
To: torikoshia <torikoshia@oss.nttdata.com>
cc: Pgsql Hackers <pgsql-hackers@postgresql.org>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails
In-reply-to: <5bafa66ad529e11860339565c9e7c166@oss.nttdata.com>
References: <5bafa66ad529e11860339565c9e7c166@oss.nttdata.com>
Comments: In-reply-to torikoshia <torikoshia@oss.nttdata.com>
	message dated "Tue, 07 Sep 2021 12:41:02 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3208198.1631039493.1@sss.pgh.pa.us>
Date: Tue, 07 Sep 2021 14:31:33 -0400
Message-ID: <3208199.1631039493@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3208199.1631039493%40sss.pgh.pa.us>
Precedence: bulk

torikoshia <torikoshia@oss.nttdata.com> writes:
> While working on [1], we found that EXPLAIN(VERBOSE) to CTE with SEARCH 
> BREADTH FIRST ends up ERROR.

Yeah.  It's failing here:

                     * We're deparsing a Plan tree so we don't have a CTE
                     * list.  But the only place we'd see a Var directly
                     * referencing a CTE RTE is in a CteScan plan node, and we
                     * can look into the subplan's tlist instead.

                    if (!dpns->inner_plan)
                        elog(ERROR, "failed to find plan for CTE %s",
                             rte->eref->aliasname);

The problematic Var is *not* in a CteScan plan node; it's in a
WorkTableScan node.  It's not clear to me whether this is a bug
in the planner's handling of SEARCH BREADTH FIRST, or if the plan
is as-intended and ruleutils.c is failing to cope.

Either way, this deserves an open item...

			regards, tom lane