Exactly. Also agree SQLite is often used stand-alone. Richard already has a mini-scripting language around, [TH1](https://fossil-scm.org/home/doc/trunk/www/th1.md), which is not my cup of tea, being TCL based (and thus entirely string-based), but simplicity matters in this context, and the fact it's already Richard's code helps a lot too. With a few extended commands to gain access to the SQL engine, for *dynamic SQL*, different from those used by Fossil, and you have most of what's needed for *Stored Procedures*, which Richard can decide to put in a reserved-name table `sqlite_proc` for example. Put that in the amalgamation, with an opt-in flag, and you have all the ingredients necessary. Sure a DB with these features would not be properly understood by older clients, but the same is true of many new SQLite features, and over times most clients would support them. Where things fall down is for Richard to see the need for all that, and given the additional maintenance burden (shared with Fossil though, in part), and the fact his main uses of SQLite are embedded, where you have the full C language at your fingertips. Maybe it will come one day, but I doubt it.