kyleconroy
commented
2 weeks ago I very much like the WASM plugin based approach of supporting different programming languages.
I do too! The interface has worked out well for the project. I'm hoping that as WASI Preview 2 support lands in more places we'll be able to offer a much richer plugin interface to address some of the limitations. See https://github.com/sqlc-dev/sqlc/discussions/3433 for a good list.
does SQLC welcome community contributions of new SQL engines?
Sadly, the answer right now is no. It's not because I don't want to.
The first issue is that I have big plans for the database driver interface over the next six months. Our current database-backed analyzer is tacked onto our existing analyzer. I want to switch to a pure database analyzer, which will improve accuracy and solve many of our open bugs.
However, until that switch is made, I don't want to add additional database drivers.
The second issue is about WASM. Codegen plugins work because they don't need to talk to the network. WASM doesn't have good support for talking to databases yet, and until wazero / go-wasmtime do, we'd have to only support process-based plugins, which are difficult to distribute.
I very much like the WASM plugin based approach of supporting different programming languages.
I was wondering if there is any thought of applying that same logic to db drivers - it would be awesome, and would integrate much better with existing SQL parsing tooling.
In that context but a slightly different question - does SQLC welcome community contributions of new SQL engines?