diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-15 16:10:48 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-15 16:10:48 -0500 |
| commit | 9cebe49524af365d48f9e63048c79f537d6b135c (patch) | |
| tree | a960704df20ced28a150036da0d3f7d73aed18ad /src/backend/parser/parse_utilcmd.c | |
| parent | a87d7801c24ffb3593841838ba0e3d4883d34853 (diff) | |
| download | postgresql-9cebe49524af365d48f9e63048c79f537d6b135c.tar.gz postgresql-9cebe49524af365d48f9e63048c79f537d6b135c.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/parser/parse_utilcmd.c')
0 files changed, 0 insertions, 0 deletions