> Not only the implementation of qsort would have to be visible to the compiler, but also the implementation of the comparison function, which may be defined in a separately compiled module or passed around dynamically as a function pointer (as might qsort itself, potentially).

In postgres' case the whole set of comparison functions isn't know at the compile time of the server - new types / operators can be added at runtime by extensions.

Hence the branches for the few most common/performance critical cases. I'd personally prefer if we gradually moved to C++ in postgres, but that'd not change that we'd need to have those explicit branches to benefit from a faster sort.

Of course it'd be a lot less annoying to implement in C++ - manually implementing templates with macro magic is many things, but not fun.

It's pretty straightforward to have a qsort() or bsearch() clone generated by a macro alongside a static inlined comparison function. You will get C++ level performance out of that.