Redesign ToSql to be implementable without `unsafe` about rusqlite HOT 6 CLOSED

There is one thing that can greatly reduce copy but not currently supported by rusqlite is binding reuse:

sqlite3 *db = NULL;
sqlite3_stmt *stmt = NULL;
int rc = 0;
rc = sqlite3_open_v2(":memory:", &db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, NULL);
if (db == NULL || SQLITE_OK != rc) {
    fprintf(stderr, "Error: unable to open database: %s\n", sqlite3_errmsg(db));
    exit(1);
}

rc = sqlite3_prepare_v2(db, "SELECT ?", -1, &stmt, NULL);
if (stmt == NULL || SQLITE_OK != rc) {
    fprintf(stderr, "Error: prepare stmt: %s\n", sqlite3_errmsg(db));
    exit(1);
}
// Bind once
rc = sqlite3_bind_int(stmt, 1, 1);
if (SQLITE_OK != rc) {
    fprintf(stderr, "Error: bind param: %s\n", sqlite3_errmsg(db));
    exit(1);
}
// Reuse many times...
for (int i = 0; i < 10; i++) {
    rc = sqlite3_step(stmt);
    if (SQLITE_OK != rc && SQLITE_DONE != rc && SQLITE_ROW != rc) {
        fprintf(stderr, "Error: %s\n", sqlite3_errmsg(db));
        exit(1);
    }
    sqlite3_reset(stmt);
}
sqlite3_finalize(stmt);
sqlite3_close(db);

It seems difficult to make binding reusable when the data is borrowed...

from rusqlite.

Ahh, yeah, that's interesting. I don't think it affects the ToSql trait, since that's used in the "binding" step. Getting this reuse would require a different way of calling query/execute. Something like query_with_previous_parameters? I don't think borrowed data is a concern with this since SQLite makes its own copy when you bind, right?

from rusqlite.

SQLite makes its own copy when you bind

only when SQLITE_TRANSIENT is specified.

from rusqlite.

True, but we always specify it. :-)

So there are at least two things we could do:

• (Easy, I think) Add ability to reuse bound parameters. Maybe Statement gets a method like bind_parameters(&[&ToSql]) -> BoundStatement, and BoundStatement has all the query... methods but they don't need params.
• (Hard, I think) Add ability to bind text/blobs without SQLITE_TRANSIENT.

The first one is orthogonal to a new ToSql interface. The second definitely isn't, but I don't have any ideas off the top of my head how we could allow that safely.

from rusqlite.

At least, we can use SQLITE_STATIC with sqlite3_bind_text when the text is empty ("").
And we can use sqlite3_bind_zeroblob instead of sqlite3_bind_blob when the byte slice is empty.

from rusqlite.

True - both of those can be done internally. I'm not sure what the lifetimes on a variant of prepare(&[&ToSql]) would look like if we wanted to tie them to the lifetime of the returned statement, or if it's even possible to express that. I wonder if we could use borrowed data more easily for the one-shot functions like Connection::execute and Connection::query_row.

from rusqlite.