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

On Fri, Aug 9, 2024 at 4:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> However, after testing it I got less excited, because it caused
> quite a lot of regression test changes (which I didn't bother to
> include in 0001). Many of them seem like significant readability
> lossage, for example
>
> GroupAggregate
> - Group Key: pagg_tab1.y
> + Group Key: (NULL::integer)
> -> Sort
> - Sort Key: pagg_tab1.y
> + Sort Key: (NULL::integer)
> -> Result
> One-Time Filter: false

Yeah, it seems that the original tlist of a dummy Result is needed to
deparse upper plan nodes. With 0001, expressions that should be
matched to lower tlist might end up with all NULLs, which seems not
great.

> So I'm coming around to doing something like the quick hack you
> proposed. I don't like it too much because it seems like it could
> make other bugs in this area much harder to notice, but I don't have a
> better idea. We do need some work on the outdated comments though.
> Also, I think we should use "f%d" not "col%d" by analogy to the
> default field names for RowExprs and anonymous record types.

Agreed. Do you think it would be helpful to add some assertions to
verify the plan type? For example, if dpns->inner_plan is NULL, the
plan should be a Result node; otherwise, it must be a SubqueryScan
node (or in the RTE_CTE case, it must be a CteScan/WorkTableScan
node).

Thanks
Richard