]> granicus.if.org Git - postgresql/commit
Make new expression eval code reject references to dropped columns.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Mar 2017 22:05:03 +0000 (18:05 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Mar 2017 22:05:14 +0000 (18:05 -0400)
commit2c4debbd0f018aa7322b622c88424a7f68d3081d
treece2206022d95616293b05b2be7c20832092afb99
parentce96ce60ca2293f75f36c3661e4657a3c79ffd61
Make new expression eval code reject references to dropped columns.

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.

Discussion: https://postgr.es/m/16803.1490723570@sss.pgh.pa.us
src/backend/executor/execExprInterp.c
src/test/regress/expected/create_view.out
src/test/regress/expected/rangefuncs.out
src/test/regress/sql/create_view.sql
src/test/regress/sql/rangefuncs.sql