Such lessons are a motivating factor behind wishes to *not* increase the ongoing legacy function debt. Say drh writes this `stddev()` function, and in his typical "lite" style doesn't provide support for probability density functions, or implements it as sample standard deviation and not population standard deviation, or both. This will doubtless satisfy some subset of the users wanting this, but then someone will come along and want the improvements. Do we then have two or three `stddev()` type functions, one or more of which is deprecated? If you think that's an unreasonable worry, click that PostgreSQL link up-thread. Or, what about Keith's worries about implementation details involving loss of precision and such due to pathological FP arithmetic behaviors? If it's written in the "lite" style implied by the links up-thread showing the theoretically-right but wrong-in-practice algorithms, does the same thing occur in a few years when that implementation is replaced by a version using clever numerical methods to avoid the problems? But oh, you say, if the latter occurs, SQLite will just get an improved implementation; why would we need a second implementation? Wouldn't the new one just replace the old? The answer is, no, because people depend on wrong behavior all the time, and SQLite goes to uncommon lengths to preserve old behaviors for the benefit of such people. Thus the deprecated but still available functions, the `ifdefs` to restore legacy mechanisms, the `_v2` and `_v3` C API functions... So yeah, I do expect implementing statistics functions to be an ongoing source of code churn, one best left either to an extension or to the host language's libraries, wrapped for the benefit of SQLite as application-defined functions.