Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I'm just considering the best fix and can think of two options:

> 1) Move away from using varno==0 in generate_append_tlist(). Use varno==1, or;
> 2) Add handling in setrefs.c for T_Result to adjust varno==0 Vars to
> use varno==1 vars.

> The attached v4-0001 does #2, but wondering if #1 should be explored first.

I don't recall the details ATM, but if you poke around you will find
multiple comments complaining about how that varno-zero convention is
problematic or requires code to do something unusual. So I'd be in
favor of trying to get rid of it, but I'm not entirely sure what to do
instead, and the ramifications might be wider than you realize.

In particular it's not clear to me why varno==1 is better? As best
I can recall without diving into code, the fundamental mismatch is
that varno zero doesn't correspond to any RTE. It would be better
if the Vars matched the subquery RTEs that are at the base of the
set-operation nest, so that there were a useful referent as to where
a Var came from. Arbitrarily setting varno=1 sounds like the worst
case: we could neither identify a Var with a source subquery
accurately, nor realize that its varno is phony.

regards, tom lane