diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-10-25 17:35:19 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-10-25 17:35:19 -0400 |
commit | 13d53aa7a83383c9d1343e7d725e615f8678aea8 (patch) | |
tree | 1bd462e7b0ca9171de592bde2f5ae2c1f7f67673 /src/backend/executor/nodeSort.c | |
parent | 0e972f50fdc9f33b01d02bbcc2f26aa32f1c58ab (diff) | |
download | postgresql-13d53aa7a83383c9d1343e7d725e615f8678aea8.tar.gz postgresql-13d53aa7a83383c9d1343e7d725e615f8678aea8.zip |
Doc/improve confusing, inefficient tests to locate CTID variable.
The IsCTIDVar() tests in nodeTidscan.c and nodeTidrangescan.c
look buggy at first sight: they aren't checking that the varno
matches the table to be scanned. Actually they're safe because
any Var in a scan-level qual must be for the correct table ...
but if we're depending on that, it's pretty pointless to verify
varlevelsup. (Besides which, varlevelsup is *always* zero at
execution, since we've flattened the rangetable long since.)
Remove the useless varlevelsup check, and instead add some
commentary explaining why we don't need to check varno.
Noted while fooling with a planner change that causes the order
of "t1.ctid = t2.ctid" to change in some tidscan.sql tests;
I was briefly fooled into thinking there was a live bug here.
Diffstat (limited to 'src/backend/executor/nodeSort.c')
0 files changed, 0 insertions, 0 deletions