The implementation of that function was left empty, but that
can lead to wrong query results: If the foreign scan is on
the inner side of a nested loop join, the order of function
calls is as follows:
tdsBeginForeignScan
tdsIterateForeignScan (until done)
tdsReScanForeignScan (prepare for second loop iteration)
tdsIterateForeignScan (until done)
... (repeat the last two for each loop)
tdsEndForeignScan
Since "tdsReScanForeignScan" didn't do anything, the second
and all following scans will not return any rows, since the
result set is already exhausted.
This leads to wrong query results.
To fix, consume any remaining rows and reset the state.
The implementation of that function was left empty, but that can lead to wrong query results: If the foreign scan is on the inner side of a nested loop join, the order of function calls is as follows:
tdsBeginForeignScan tdsIterateForeignScan (until done) tdsReScanForeignScan (prepare for second loop iteration) tdsIterateForeignScan (until done) ... (repeat the last two for each loop) tdsEndForeignScan
Since "tdsReScanForeignScan" didn't do anything, the second and all following scans will not return any rows, since the result set is already exhausted.
This leads to wrong query results.
To fix, consume any remaining rows and reset the state.