This is part of an argument that an in-process, single-file, zero-admin SQL database is a completely different animal from an interface to SQL database servers, and deserves its own API, though it should not be *gratuituously* different. The existence of sql-de-lite and APSW (Python) seemed to confirm this. Once you exclude the proprietary, the JVM, and the .NET databases, only SQLite and Firebird Embedded are left, and SQLite is far more lightweight.

My actual pre-SRFI isn't particularly SQLite-specific, but it's what I think of as the MVP; other SQLite-specific features can be added in a later SRFI. If it's useful as a skeleton for a general database server API, that's certainly a Good Thing.

On Mon, Sep 16, 2019 at 2:42 AM Peter Bex <xxxxxx@more-magic.net> wrote:

On Sun, Sep 15, 2019 at 09:34:08PM -0400, John Cowan wrote:
> One of the other things that makes SQLite different is the ability to
> define scalar and aggregate functions, as well as collations, on the fly.

I'd say treat it as an extension. This is so different from the typical
client/server database that it doesn't make much sense to standardise in
the API.

Similar for LISTEN/NOTIFY in Postgres, as a random example which also
involves callbacks.

Cheers,
Peter