Fix index-only scan plans when not all index columns can be returned.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 1 Jan 2022 21:12:03 +0000 (16:12 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 1 Jan 2022 21:12:03 +0000 (16:12 -0500)
commitf789b7732e0b535fe2588879a60f536abfb6c6e0
tree8ce128db07d33d855c51da0354879786f1d6ca01
parentd536d0304b7891fdf5c74f0077f4de45290f6f63
Fix index-only scan plans when not all index columns can be returned.

If an index has both returnable and non-returnable columns, and one of
the non-returnable columns is an expression using a Var that is in a
returnable column, then a query returning that expression could result
in an index-only scan plan that attempts to read the non-returnable
column, instead of recomputing the expression from the returnable
column as intended.

To fix, redefine the "indextlist" list of an IndexOnlyScan plan node
as containing null Consts in place of any non-returnable columns.
This solves the problem by preventing setrefs.c from falsely matching
to such entries.  The executor is happy since it only cares about the
exposed types of the entries, and ruleutils.c doesn't care because a
correct plan won't reference those entries.  I considered some other
ways to prevent setrefs.c from doing the wrong thing, but this way
seems good since (a) it allows a very localized fix, (b) it makes
the indextlist structure more compact in many cases, and (c) the
indextlist is now a more faithful representation of what the index AM
will actually produce, viz. nulls for any non-returnable columns.

This is easier to hit since we introduced included columns, but it's
possible to construct failing examples without that, as per the
added regression test.  Hence, back-patch to all supported branches.

Per bug #17350 from Louis Jachiet.

Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
src/backend/optimizer/plan/createplan.c
src/include/nodes/plannodes.h
src/test/regress/expected/gist.out
src/test/regress/sql/gist.sql