aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeBitmapOr.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-11-15 16:10:48 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-11-15 16:10:48 -0500
commit4ac8ee9d4878dadccc2331d8d1b1769c97f4ebe9 (patch)
tree1fbe7fb893928fb273668e2ba2cf4ea54b99065e /src/backend/executor/nodeBitmapOr.c
parent2b77595085423970036afd6263046c5747534dd0 (diff)
downloadpostgresql-4ac8ee9d4878dadccc2331d8d1b1769c97f4ebe9.tar.gz
postgresql-4ac8ee9d4878dadccc2331d8d1b1769c97f4ebe9.zip
Fix fuzzy thinking about amcanmulticol versus amcaninclude.
These flags should be independent: in particular an index AM should be able to say that it supports include columns without necessarily supporting multiple key columns. The included-columns patch got this wrong, possibly aided by the fact that it didn't bother to update the documentation. While here, clarify some text about amcanreturn, which was a little vague about what should happen when amcanreturn reports that only some of the index columns are returnable. Noted while reviewing the SP-GiST included-columns patch, which quite incorrectly (and unsafely) changed SP-GiST to claim amcanmulticol = true as a workaround for this bug. Backpatch to v11 where included columns were introduced.
Diffstat (limited to 'src/backend/executor/nodeBitmapOr.c')
0 files changed, 0 insertions, 0 deletions