Build SQLite with SQLITE_ENABLE_PERCENTILE for Windows and CPython-3.15+

[WKarel]

Feature or enhancement

Proposal:

For Windows, CPython-3.15 requires SQLite-3.53.2. Since 3.51.0, the aggregate functions median and percentile are part of SQLite's amalgamation. I believe that this means that they are found to be mature. To have them available at run-time, SQLite needs to be built with SQLITE_ENABLE_PERCENTILE. Python's PCBuild activates a few built-in extensions of SQLite, but not this one yet.
Inserting SQLITE_ENABLE_PERCENTILE here might be everything needed.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

I have not found previous discussions on this topic.

This discussion is about the ability to load SQLite extension modules at run-time, which is somehow related, as it can be used as an (inconvenient) fallback.

Another fallback is to implement these statistical functions in Python and bind them to a data base connection. This works, but is slower than having them built into SQLite (76s vs. 68s in my non-repesentative query).

Linked PRs

• gh-152023: Update macOS installer builds to SQLite 3.53.3 #153867
• [3.15] gh-152023: Update macOS installer builds to SQLite 3.53.3 (GH-153867) #153869
• gh-152023: Update Android and Windows builds to SQLite 3.53.4 #155101
• [3.15] gh-152023: Update Android and Windows builds to SQLite 3.53.4 (GH-155101) #156048
• gh-152023: Update macOS installer builds to SQLite 3.53.4. #156446
• [3.15] gh-152023: Update macOS installer builds to SQLite 3.53.4. (GH-156446) #156448

[StanFromIreland]

Our requirement is currently SQLite 3.15.2, as noted in the documentation. The file you're linking to is just what we use to pull our stored dependencies when we build Windows releases. Other redistributors (e.g., Astral's products, Homebrew, or Debian) need not use the same version.

[WKarel]

@StanFromIreland I missed that. Sorry for the noise.

[StanFromIreland]

It doesn’t mean we can't expose them when available (if they are actually useful to users), we already do so for other APIs. But this isn't my area, so I'll leave this up to @erlend-aasland :-)