> It'll likely be 2-3 more days before I have a first version

2-3 days is nothing :) Most commercial projects would love to ship stuff
as fast as we are doing.

> For error representation, isn't there's a degree of commonality from
> database engines we can start with, an short error code, and at least
> one string?

This is a good point. I currently return errors from the subprocess like
this:

(error args "wrong number of args")
(error state "not connected to database")
(error state "not finished executing another statement")
(error database "table hello already exists")

So there's a symbol that gives the error code (args/state/database), and
then a human-readable message. I'd like the rest of you to tell me which
codes to use :) You'll have a better grasp of what granularity is
useful. SQLite can easily return quite precise codes, and I assume the
big databases are even better at it.

I think the main point is to have some solid error classes that the
programmer can rely on, instead of a generic catch-all error. At a minimum:

* Did I call the DB API in a way that cannot possibly work (wrong number
of args, wrong data types, etc)?

* Did I call things in the wrong order (execute before connect, rollback
outside transaction, etc)?

* Did I send bad SQL? Bad parameters for a parameterized statement?
Multiple SQL statements when only a single one was expected?

* Is the database experiencing intermittent failure (network or disk
failure, quota exceeded, temporarily too high load, etc)