>> Fixed. However, I have added a database-type symbol that specifies which driver to use.

Nice. We need to keep a table of all the known symbols somewhere.

> Or that could be part of the plist that Lassi strongly suggests we use instead of a connect string. Which would also address my config desire.

Here's a list of all the connection parameters accepted by a recent
version of PostgreSQL:
<https://www.postgresql.org/docs/9.1/libpq-connect.html>. Encoding all
of those into one string would be grounds for a
bewildering-sexpr-reinvention-of-the-week award :)

>>> Why not assume success and commit on the completion of the thunk, and require an explicit rollback?
>>
>> I can't make up my mind what's best here. Can you provide some arguments?
>
>   * Smaller API surface
>   * Code is more concise, closing paren of with-transaction instead of a call to a commit procedure
>   * When would you commit other than at the end of a with-transaction?
>   * Normal flow of control assumes success which is normal, the rollback procedure acts like an exception (may well be implemented as one).
>   * This is almost how the Clojure Korma DSL does it ^_^. But seriously, it works very well.

I agree with these arguments.

A particularly strong one is that with manual commits, forgetting to
commit at the end drops user data on the floor and silently "succeeds".
Speaking from experience :)

> Repeating, when would you issue a commit other than as the last procedure called in a with-transaction?
>
> Whereas a rollback can happen at any time you realize "oops!!!"

I have to agree with this. An explicit commit procedure that isn't
strictly necessary can cause users to distrust the whole API since it
doesn't have "idiot-proof" rules for when to commit and when not to.

The whole commit business causes anxiety for database plebs like me to
begin with. If commits are manual, it's only a matter of time before I
forget to do it. If they are automatic, don't frighten me with false
alarms hinting manual commits might be required under circumstances I
don't understand :)

If you live and breathe databases this is probably a non-issue, but for
us plebs, a typical SQL database looks a bit like Howl's Moving Castle.

>> You might be inside transactions on two connections at the same time, as when you are copying data from one db to another.

Wow, that is true! So transactions need to have labels. Perhaps be
passed as lambda arguments to be bound to variables.

> But this requires though. Maybe blast out of all transactions? Maybe require in such a case naming which transaction you're rolling back, which would also roll back a transaction that's in the way??

I suspect an unlabeled (rollback) rolling back all active transactions
could be the least surprising alternative, and/or do the least damage.

If you throw exceptions, at least those blow up somewhere. If you don't
throw an exception, there's more danger that some strand silently
"succeeds".

> I've just found that the wide column Apache Cassandra and graph Neo4j databases have very suitable query languages to support, or rather, to see if we can not get in the way of. They're fairly popular, have what are supposed to be good C libraries, don't have SQL front ends, and aren't insanely complicated in several dimensions like Elasticsearch.
>
> There's also a serious ISO/IEC Graph Query Language effort standard in progress, according to the Neo4j people it's taking a lot from their Cypher query language: https://neo4j.com/blog/gql-standard-query-language-property-graphs/ "[...] it is highly likely that some reasonably complete draft will have been created by the second half of 2020".

Wow, cool!