sqlite-xsv

I think so - I wrote my own Rust FFI bindings for SQLite extensions, and I tried to make it as fast as possible, but a "hello world" extension was still 10-15% slower in Rust than C[0]. That being said, it depends what the extension does - a "hello world" extension mainly just calls the same SQLite C APIs over and over again, so the small Rust layer makes it a bit slower. However, my Rust extensions for regex[1] and CSV parsing[2] are usually faster than the C counterparts, mostly due to less memory allocations and batching. It's not a 1:1 comparison (both extensions have slightly different APIs and features), but I'd say a lot of "real world" features available in Rust can be faster than what's available in C. That being said, I'm sure someone could write their own faster CSV or regex extension in C that is faster than the Rust ones. But

This is such a huge step forward for the usability of custom SQLite extensions in Python world. Alex has a whole family of SQLite extensions that he's built in Rust which are worth checking out: - sqlite-xsv: https://github.com/asg017/sqlite-xsv - sqlite-fastrand: https://github.com/asg017/sqlite-fastrand - sqlite-ulid: https://github.com/asg017/sqlite-ulid - sqlite-jsonschema: https://github.com/asg017/sqlite-jsonschema - sqlite-regex: https://github.com/asg017/sqlite-regex - sqlite-url: https://github.com/asg017/sqlite-url - sqlite-http: https://github.com/asg017/sqlite-http - sqlite-lines: https://github.com/asg017/sqlite-lines - sqlite-path: https://github.com/asg017/sqlite-path - sqlite-html: https://github.com/asg017/sqlite-html

The API for virtual tables is tricky, because you don't ever consume the API in Rust: SQLite does it. However, as it is presented the interface is unsafe, I think. In the sqlite-xsv VTab::open impl for XsvTable [0], you pass a &'vtab XsvTable to XsvCursor. But the means that if open is called again, to create a second cursor, then a `&mut XsvTable` and a `&XsvTable` reference exist at the same time, which is unsafe. Note that sqlite-xsv doesn't actually keep the `&XsvTable`, so it's fine, but it serves as an example where a safety problem could surface. The same problem also applies to VTabWriteable::update. The fix is to make both of these methods receive an immutable reference and force implementors to use interior mutability. Note this isn't hypothetical, it's actually unsafe, and would appear if you had a unit test that implemented a

Author here, happy to answer any questions! Here's a few links that may be useful: Direct GitHub link: https://github.com/asg017/sqlite-loadable-rs A soon-to-be-released sqlite-loadable extension that's the fasted CSV parser for SQLite, and rivals DuckDB's parser at non-analytical queries: https://github.com/asg017/sqlite-xsv A regular expression extension in Rust, the fastest SQLite regex implementation: https://github.com/asg017/sqlite-regex And in the near future, expect more extensions for postgres, parquet, XML, S3, image manipulation, and more!