FieldSelect optimization versus overall planner organization

I looked into bug #11703,
http://www.postgresql.org/message-id/20141017162236.2523.74453@wrigleys.postgresql.org

What is happening here is that the FieldSelect optimization in
eval_const_expressions fails to play nice with the logic that determines
which Vars need to be available from a relation scan.  We start out with,
say,

select x from my_table, func2(my_table) f(x);

which inline_set_returning_functions() expands into

select x from my_table, lateral (select func1(my_table)) f(x);

At this point we decide that the sub-select can't be flattened into the
upper query (in this case, because it lacks a FROM clause, but any other
reason to suppress flattening would have the same result).  So we put the
sub-select on the back burner for the moment and start to plan the outer
query.  In particular, we determine that the only Var that the scan of
my_table has to produce is a whole-row Var ("my_table.*") to satisfy the
lateral reference in the sub-select.

Eventually, we get around to recursively planning the sub-query, and at
that point we'll inline the func1() call, producing a FieldSelect applied
to the whole-row Var for "mytable".  When we do const-simplification on
the resulting expression, that pair of nodes is reduced to a simple Var
referencing mytable.my_column.  Which ought to be fine --- except that we
already planned the scan of my_table on the assumption that it should
produce "my_table.*".  So after all the dust settles and setrefs.c is
doing the janitorial work, it finds out that the lateral reference to
mytable.my_column can't be satisfied, and you get the dreaded "variable
not found in subplan target list" error.

AFAICS, the only way to fix this "right" would require major
rearrangements of the order in which the planner does stuff, for example
insisting on doing function inlining and const-simplification all the way
down in subqueries before we plan the outer query level.  That'd be quite
a lot of work to change, and the odds of introducing new bugs are high
enough that I think back-patching would be out of the question anyway.

I think the only practical fix is to lobotomize the FieldSelect-collapsing
optimization.  It's probably safe enough to keep allowing it for whole-row
Vars of the current query level, but not those with levelsup > 0.

Anybody have another idea?
        regards, tom lane