direct-sqlite should provide lower-level access for those who need it

[joeyadams]

Currently, direct-sqlite contains FFI bindings, performs marshaling, and throws exceptions. This does not give some users enough control:

• persistent-sqlite wants to avoid unnecessary conversions.
• I want more precise error handling (e.g. distinguish between syntax errors and disk corruption) for an application I'm working on.

I propose we introduce the following alternative APIs:

• Database.SQLite3.Direct: Similar to Database.SQLite3, but:
  • Return errors instead of throwing them. Use data types to represent errors, not just strings.
  • Only use cheap conversions, meaning no String or Text. Accepting or returning UTF8-encoded ByteStrings is fine, since persistent-sqlite has to do that anyway.
• Database.SQLite3.Bindings: Direct FFI bindings and enumeration decoding functions.

Database.SQLite3 would use Database.SQLite3.Direct, and Database.SQLite3.Direct would use Database.SQLite3.Bindings.

I've already implemented Database.SQLite3.Bindings, and implemented Database.SQLite3 in terms of it. I would submit a pull request, but I'd rather wait until I'm done romping around in Database.SQLite3, to avoid clashing with other contributions. I plan to implement Database.SQLite3.Direct pretty soon.

Anyone have an issue with this? Thanks for the input.

[nurpax]

The changes to move the C low-levels into SQLite3.Bindings looks good. I like the c_sqlite3* naming convention, it makes it easier to read the code for me.

[nurpax]

can't this be closed now?