Interesting. But this uses mattn's go-sqlite3 package, which is CGO.

Is this a normal/expected requirement in modern GO?

ncruces 8 months ago | parent | next [-]

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.

▲

preetamjinka 8 months ago | parent | prev | next [-]

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.

▲

hamburglar 8 months ago | parent [-]

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.

▲

cryptonector 8 months ago | parent [-]

I bet SQLite3 builds on more platforms than Go.

	▲	catlifeonmars 8 months ago \| parent [-]
		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.

▲

cryptonector 8 months ago | parent | prev [-]

There is no pure Go implementation of SQLite3 so...

	▲	ncruces 8 months ago \| parent [-]
		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.