Love to see someone writing about vtabs, I implemented vtab support for a rust reimplementation of sqlite so I've recently learned a tremendous amount about them. They are very powerful and probably under utilized.
PS: The mattn CGO driver actually doesn't seem to support wrapping the xBegin/xSync/xRollback/xCommit methods. Mine actually does, although it's largely untested, as I haven't needed this yet.
We use mattn's go-sqlite3 in our SaaS product. It's not ideal from a toolchain perspective (i.e. cross compiling becomes a little annoying, especially with multi-arch Docker images) but once you get across that hurdle, we haven't run into any major problems with cgo.
The problem with cgo is it reduces portability, not that it causes issues. If whatever C you’re invoking doesn’t build on your architecture or if you need to cross-compile (last I checked), you’re out of luck.
It’s not about the build platform, it’s about the execution platform and not having to have a toolchain for every platform. This is especially relevant in the embedded space.
Love to see someone writing about vtabs, I implemented vtab support for a rust reimplementation of sqlite so I've recently learned a tremendous amount about them. They are very powerful and probably under utilized.
Interesting. But this uses mattn's go-sqlite3 package, which is CGO.
Is this a normal/expected requirement in modern GO?
Virtual tables are fully supported by my CGO free driver: https://pkg.go.dev/github.com/ncruces/go-sqlite3
You can have a look at a bunch of examples in my extensions folder: https://github.com/ncruces/go-sqlite3/tree/main/ext
PS: The mattn CGO driver actually doesn't seem to support wrapping the xBegin/xSync/xRollback/xCommit methods. Mine actually does, although it's largely untested, as I haven't needed this yet.
We use mattn's go-sqlite3 in our SaaS product. It's not ideal from a toolchain perspective (i.e. cross compiling becomes a little annoying, especially with multi-arch Docker images) but once you get across that hurdle, we haven't run into any major problems with cgo.
The problem with cgo is it reduces portability, not that it causes issues. If whatever C you’re invoking doesn’t build on your architecture or if you need to cross-compile (last I checked), you’re out of luck.
I bet SQLite3 builds on more platforms than Go.
It’s not about the build platform, it’s about the execution platform and not having to have a toolchain for every platform. This is especially relevant in the embedded space.
There is no pure Go implementation of SQLite3 so...
There's at least…
https://modernc.org/sqlite which preprocesses and transpiles the amalgamation from C to Go.
https://github.com/ncruces/go-sqlite3 which runs a Wasm build of SQLite through a pure Go Wasm runtime.