Hiding the concept of prepared statements, which I'm not sure are so
important nowadays, but I've got to research this, its been decades
since I had to deal with this issue, and the world has fundamentally
changed.
My SQLite pre-SRFI requires that the code string and the binding alist are both immutable once they have been passed to ssql-statement. This allows a cache of compiled but unbound statements, with or without a second cache of bound statements, to be constructed with an eq? hashtable. Or you can forget caching if compiling and/or binding is fast. As long as the new query and/or alist is eq? to the old, you can minimize statement preparation.
(By the way, ssql stands for simple SQL, but it needs to be changed because of the use of SSQL for SQL in S-expressions.)
Preventing statement injection in data; while this violates the
plumbing focus, I believe it should be enforced at the lowest level
so every use of this set of SRFIs and libraries benefits from it.
I think the Right Thing here is to use a single standard for named query parameters, which are supported by SQLite, Oracle, MySQL, and SQL Server — but not by PostgreSQL, which would require some logic to map named parameters into question marks.
Data types to the degree possible.
SQL *per se* as a query and update language, most especially the
differences between what the various databases support and how.
+1
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgWhen I wrote it I was more than a little febrile with foodpoisoning
from an antique carrot that I foolishly ate out of an illjudged faith
in the benignancy of vegetables. --And Rosta