Add extension support for SQLite

[bradfier]

Implements #1460

I was trying to find a way to use extensions (specifically vsv and spatialite) with SQLite from Rust, and while Rusqlite supports them, my perferred SQL crate did not, hence this PR to try and rectify that situation.

I found the issue mentioned above and took note of the suggestions made, that we should probably implement this as conservatively as we can, please see the commit message for more specifics.

Testing

I would appreciate some guidance on how to test this from the integration test suite. Something like this will exercise the code in question, the more difficult problem is "How do we get the extension shared object to the test context?".

#[sqlx_macros::test]
async fn it_opens_with_extension() -> anyhow::Result<()> {
    let opts = SqliteConnectOptions::from_str(&dotenvy::var("DATABASE_URL")?)?
        .extension("vsv");

    let conn = SqliteConnection::connect_with(&opts).await?;
    conn.close().await?;

    Ok(())
}

Just sticking a compiled object in isn't appropriate, as it's architecture and OS dependent, and unlike the other databases we don't spin a Docker container up, otherwise we could modify it to add an extension package.

Would it be possible to add a simple extension as a .c file and have a build.rs compile it only in a test context? sqlite3-ipaddr would be a good minimal example as it's only a few hundred lines long and has no external dependencies except for sqlite3ext.h.

[abonander]

I don't see a problem with just grabbing a precompiled binary: https://github.com/nalgeon/sqlean/releases/tag/0.15.2

This can be done in the CI script itself where the OS is known, mark the test with #[cfg(sqlite_ipaddr)] so it's not run normally, and add RUSTFLAGS: --cfg sqlite_ipaddr to the environment variables.

[bradfier]

I've added that as suggested and enabled it in x.py and in GitHub Actions. Hopefully this should run successfully, it worked in my fork when I tried it on-push.

[bradfier]

I've sorted out the CI failures, which were due to GHA's working directory not being the same between steps, see CI on my fork for a successful run.

[framp]

Thanks a lot for this!

I was wondering, how are you dealing with sqlx-cli?
There is no way to specify extensions in the connection string so you can't load extensions when running migrations

A typical usecase would be to create a geometry column with the spatialite extension

CREATE TABLE locations
...
SELECT AddGeometryColumn('locations', 'geometry', 4326, 'POINT', 2);

[yuyoyuppe]

Same issue here. My migrations must contain BLOB data, so I was going to use readfile.