> Just because it is experimental should not exclude it from being in the standard apis and flagged as experimental and subject to change Occasionally, as new API functions and features are introduced, there is an interval prior to release when they are marked (or flagged) as you suggest. This is rarely done with anything that goes into released SQLite versions. It would take more than developer convenience to motivate a break with this practice, I think. > Yes of course I can hack the code around and include it myself in the core SQLite dll ... If your term "hack" includes editing<sup><b>a</b></sup>, you may find a useful feature in recent sqlite3.c amalgamations where the preprocessor symbol SQLITE_CUSTOM_INCLUDE is used. > \[W\]hy add functionality to the command line tool only rather than including it in the core dll\[?\] "SQ<b>Lite</b>"'s spelling indicates much of that why. The rest relates to the burden of maintaining a stable API over decades. > (so that it can be used as standard in many more scenarios) I sense a tension here, between "standard" and "experimental". (my $.02) > I see it as a missed chance to only include it in the command line tool\[.\] Well, you could include it in your application(s), the one(s) you wish could use it as part of the SQLite library. The CLI shell is such an application, so the mechanism of including it yourself is there for the study or taking. ---- a. In my parlance, modifying source to make it do what I want is not necessarily a "hack".