Re: BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"

shihao zhong <zhong950419(at)gmail(dot)com> writes:
> 928df067d1e handles a plain Var in the dummy Result's tlist. Here
> the Var is under an int to numeric cast, so set_plan_refs() misses
> it.
> The attached patch walks the whole expression. It keeps the
> varno 1 rewrite, so for a nested setop the name shown can come from
> another child, as in the new test's output.

Good catch, but there's another problem here. I wondered why the
Result is claiming to output "two", when that is not either of
the columns being output by the removed setop leaf queries.
This same code is at fault: it's injecting varno "1" without
regard for which of the leaf queries are actually represented.
Fortunately, now that we have Result.relids, it's pretty easy
to discover which leaf queries are represented and choose the
leftmost one. Hence, v2 attached.

By the way, I'm still not super happy about

+ Replaces: Aggregate on unnamed_subquery, unnamed_subquery_1

when there is no aggregation going on anywhere. But that's
because Robert took shortcuts: show_result_replacement_info
does

case RESULT_TYPE_UPPER:
/* a small white lie */
replacement_type = "Aggregate";
break;

without regard for the actual reason the Result got injected.
I recall complaining about that and Robert not wanting to add
yet more complexity to what he was doing. Which is fair,
but I still think we're gonna get bug reports about this.

regards, tom lane