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

I wrote:
> I wonder if we shouldn't change what the planner puts into the tlist
> of a dummy Result. That is, I'm imagining reducing the tlist of
> such a Result to null Consts that would serve to show the right column
> datatypes and not much else:

> Result
> Output: NULL, NULL
> One-Time Filter: false

I experimented with this, and was interested to find that there's
basically only one place we could do it in a low-level, localized
fashion, namely in set_plan_refs' handling of Result nodes; if you try
to do it earlier then set_upper_references fails when there's an upper
plan node that should copy such a column's value. And there's
*already* an ugly hack there, which we could replace with a more
general hack. See 0001 attached.

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

and in a few cases I feel like the change actually means that the
test no longer proves what it intends to, because significant
details vanish into a sea of NULLs.

Another problem, which we could probably work around, is that this
breaks removal of trivial SubqueryScan nodes in some cases, because
that happens even later and the tlists no longer match.

So I feel like my idea is a dead end. Even without the above
problems, a significant change in EXPLAIN's behavior in back
branches would be a hard sell --- the more so if it's to fix
a case that nobody even noticed for eight years.

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.
See 0002 attached.

regards, tom lane