aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeSort.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-10-25 17:35:19 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-10-25 17:35:19 -0400
commit13d53aa7a83383c9d1343e7d725e615f8678aea8 (patch)
tree1bd462e7b0ca9171de592bde2f5ae2c1f7f67673 /src/backend/executor/nodeSort.c
parent0e972f50fdc9f33b01d02bbcc2f26aa32f1c58ab (diff)
downloadpostgresql-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