Thanks for raising this. On Sun, 24 Apr 2022 at 12:59, Noah Misch <n...@leadboat.com> wrote: > This (commit 77bae39) did not change function parameter counts, and > TUPLESORT_RANDOMACCESS generally has same the same numeric value as "true". I > get no warning if I pass "true" for the "sortopt" flags parameter. Hence, I > suspect this did not break the API. Should we be happy about that? I'm fine > with it.
I'd be open to doing something like make sortopt the first argument of each of the tuplesort_begin* functions if people have concerns about this causing problems. However, given that TUPLESORT_RANDOMACCESS and true likely have the same value, it seems we'd be more likely to break code down the line if we added some option that's needed that wouldn't get set by passing "true" as the sortopt. If anyone was to use tuplesort_set_bound() without updating their tuplesort_begin* then on non-assert builds, nothing would misbehave. There's just a risk of having bad memory fragmentation from using the generation context for bounded sorts. David
