parquet_sorting_oracle Module

The TEST-ONLY C++ sort engine, bound into the argsort tier at run time.

This module exists so that the rest of the sorting stack does not have to name parquet_bindings. src/parquet_wrapper.cpp carries a second, independent implementation of the ordering, kept purely so the conformance tests can check the Fortran engine against it. If parquet_argsort or parquet_sorting called it directly, every program that sorts anything -- including one whose only import is use parquet_sampling -- would pull parquet_bindings, and with it the whole Arrow stack, into its use graph. Reaching it through procedure pointers instead means a program that never imports THIS module never compiles it, and fpm prunes it away.

Selecting the C++ engine and binding it are one act, deliberately. Fortran has no module initialiser, so a design where something else has to remember to register these entry points would fail silently the first time someone forgot -- the selector would find a null pointer, and any fallback would make the A/B comparison run the Fortran engine against itself and pass. So the SETTER lives here rather than beside the flag it writes: parquet_debug_use_fortran_sort_engine binds the pointers before it changes the flag, which makes the unbound state unreachable. The getter, parquet_debug_using_fortran_sort_engine, stays in parquet_argsort with the flag.

It also refreshes the C++ side's settings mirror, because the C++ engine is the one consumer of a mirrored knob that is not downstream of a reader or writer open -- a pf_argsort call needs no file. Without this the A/B would compare the two engines under DIFFERENT sort_counting_path and sort_counting_bucket_limit values, which still passes whenever the two happen to agree.

No library code imports this module, it appears in no doc/pages/ guide, and it is absent from README.md's API overview -- the same conventions every other parquet_debug_* hook follows.