So a table where SQL strings are weak references pointing to sqlite_stmt
foreign objects?
They aren't actually weak references, but soft references: that is, they break when there is too much memory pressure as opposed to when there are no other references. In this case "memory pressure" means within the cache, not general memory. I think that weak-reference behavior (i.e. removing the string when it is GCed on the Scheme side) is not really necessary.
And it's probably good enough to compare the strings
using eq?.
Depends where it is. If it's on the C side, you don't want to do that because gc, hence the idea of a string hash. If it's on the Scheme side eq? is probably good enough.
If you want to optimize for speed, then (sql-do `("mumble @a @b @c
mumble" a ,a b ,b c ,c)) is a bit wasteful as well. SQLite uses
positional parameters internally, and the user must convert named
parameters to positional ones using sqlite3_bind_parameter_index().
I can't believe the additional cost is worth the loss of clarity and readability. It's true that PostgreSQL doesn't support named parameters in binding, but worst-case we can parse them out ourselves and replace them with the $nn format. One nice thing about @ is that it can be replaced pretty uniformly except within strings and "-quoted identifiers, as it has no meaning in any SQL dialect (which is not true of :).
If the statement stays the same, then the name->position mapping stays
the same as well and should be cached. Further, destructuring an
alist/plist on every call to unpack parameter values is unnecessary effort.
Good point.