Sorry if I was unclear in my previous comments, I plan on doing my
FFI and/or socket versions after/along with the Scheme-side API.  It'll
likely be 2-3 more days before I have a first version, but it's my
#1 priority after I get a couple of RL and administrivia things done.

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?

Error handling is not something I'm thinking about yet, and probably
deserves serious discussion on the list.  E.g. what if anything should
be done by error returns, vs. raising exceptions?

- Harold

----- Original message -----
From: Lassi Kortela <xxxxxx@lassi.io>
Date: Tuesday, September 17, 2019 1:54 PM

I'd like to finish C subprocess implementations of SQLite and Postgres.
Harold is interested in doing FFI and/or socket versions.

Can someone start throwing together a spec for the Scheme-side API that
hides the differences between the database implementation techniques, so
that we'd have an increasingly lucid goal toward which to push our
implementations? I.e. at the level where the user gives a SQL string
with parameters, says to execute it and reads rows, maybe uses
transactions, etc. Also what kind of error representation and error
handling policy is used on the Scheme side.

My subprocess interface is ready to be nudged into whichever direction
the rest of you choose :) I'd like to follow other people's lead on API
design.