Thanks for raising this.
On Sun, 24 Apr 2022 at 12:59, Noah Misch <noah@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
