From: John Cowan <xxxxxx@ccil.org>

Date: Wednesday, July 10, 2019 5:20 PM

On Wed, Jul 10, 2019 at 6:10 PM <xxxxxx@ancell-ent.com> wrote:

Depend on subject domain experts like the SQLite team and their whole
software stack when you need the best guarantees available today. Ah,
along with notes about system configuration details and trade-offs.

While I'm at it, I would very much like to see a SQLite-specific SRFI along the lines of Chicken's sql-de-lite egg <http://wiki.call-cc.org/eggref/5/sql-de-lite#high-level-interface>, as distinct from a general-purpose SQL RDBMS interface.

What do you like about it?

At first glance, the High-level interface looks very general, except for statement preparation which should be hidden for the normal user, and exposing transaction types and details. Even the error handing is general if you change or remove the sqlite- prefix, like SQLite all the RDBMSes I've used in anger have short error symbols or numbers plus a longer message string (DB-2, Oracle, and PostgreSQL). Ditto the Low-level interface I looked less closely at, even the interface for returning the type of a column isn't really specific to SQLite, except others have lengths for some types.

Not sure if other databases will easily cough up DDL that will define the schema, but printing current schema is standard.

Databases come and go, and SQLite appears to have a low bus factor and suffers from political maladroitness, I wouldn't want to lock the Scheme community into using it. For a basic library at this level, I was thinking of starting with one of the existing working SQLite or PostgreSQL libraries and making it work with both, but I want to research ODBC and JDBC first to see if they offer any useful insights.