Formerly, a Var referencing an already-dropped column was allowed and would always produce a NULL value. However, that behavior was implemented in slot_getattr which the new expression code doesn't use; thus there is now a risk of returning theoretically-deleted data. We had regression test cases that purported to exercise this, but they failed to expose any problem, apparently because plpgsql filters the dropped column and produces an output tuple that has a NULL there already.
Ideally the DROP or ALTER attempt in these test cases would get rejected due to dependency checks; but until that happens, let's modify the behavior so that we fail the query during executor start. This was already true for the related case of a column having changed type underneath us, and there's no obvious reason why we need to be laxer for dropped columns.
In passing, adjust the error messages in CheckVarSlotCompatibility to include the composite type name. In the cases shown in the regression tests this is always just "record", but it should be more useful in actual stale-plan cases, where the slot tupdesc would be a table's tupdesc directly.
2c4debb Make new expression eval code reject references to dropped columns.
src/backend/executor/execExprInterp.c | 45 ++++++++++++++---------------
src/test/regress/expected/create_view.out | 47 +++++++++++++++++++++++++------
src/test/regress/expected/rangefuncs.out | 19 ++++++-------
src/test/regress/sql/create_view.sql | 25 ++++++++++++++--
src/test/regress/sql/rangefuncs.sql | 6 ++--
5 files changed, 95 insertions(+), 47 deletions(-)