Dynamic filters (SQLite & MySQL support, sqlc.slice() integration, dialect-aware SQL lexing)

[orlandoc01]

Hi @vtuanjs, first off thanks for this plugin. The -- :if dynamic-filter idea let me delete a whole layer of hand-rolled, ugly-looking query-builder code from some side projects I use sqlc in and I've been happily building on it since.

However, when I first tried to use this plugin it failed outright for me. My projects use SQLite and it seems the dynamic filters only worked on PostgreSQL (the runtime only understood $N placeholders, and the database/sql template emitted the Build(...) call and the query call glued onto one line, which doesn't compile). So I forked it and added sqlite support and some other things I thought might be helpful for maintaining support for SQLite, Postgres and mySQL. This PR contributes everything back in case you'd like it upstream.

What's included

• SQLite support for emit_dynamic_filter — numbered ?N input placeholders normalized to $N output (valid positional syntax for the common SQLite drivers), [bracket] identifiers lexed correctly, and a Docker-free e2e test against a real SQLite database wired into CI.
• MySQL support — bare ? placeholders numbered by appearance and emitted back as ?, selected by engine: mysql alone (sql_driver still honored if used), with backtick identifiers and backslash-escaped strings lexed correctly, plus an e2e test against a real MySQL 8 container.
• sqlc.slice() inside dynamic queries (all three engines) — /*SLICE:name*/ markers are numbered at generation time and expanded at Build time; repeated slices reuse their placeholders on numbered-placeholder engines; nil/empty slices render NULL exactly like sqlc's non-dynamic expansion, and a :if-gated nil slice skips the clause entirely (empty keeps it — see the update below).
• Dialect-aware lexing — Previously '?1' inside a string literal could be rewritten or $2 inside a comment was counted as an argument. Now, annotations and bind markers are only recognized in SQL code context. String literals (including Postgres $$…$$ / $tag$…$tag$ and E'…', MySQL backslash escapes), quoted identifiers, comments, and multi-line strings with them are all ignored.
• Per-engine example layout — the example module now treats PostgreSQL like the other engines instead of as the implicit default. Sources live in example/postgres/ (like example/mysql/, example/sqlite/), generated code in dbpostgres (like dbmysql, dbsqlite), and e2e suites in e2e-{postgres,mysql,sqlite} with matching make example-e2e-<engine> targets (make example-e2e runs all three).
• Hardening and performance — fixes for panics and invalid SQL on slice edge cases (repeated empty slices, marker text without a placeholder), fewer per-call heap allocations in Build (21-param benchmark: 36 → 15 allocs/op, ~13% faster), a CI check that committed generated code matches the templates (sqlc generate + git diff --exit-code), and README doc updates for all of the above.

Changes
The only behavior change I made from your original code was regarding empty slices. An empty slice on a :if condition now skips the clause the same way nil does, so an empty list no longer silently matches zero rows. This is called out in the README and the one PostgreSQL e2e case that asserted the old behavior was updated to match.

UPDATE (2026-08-10): Reverted per the discussion below in this PR. Nil and empty are distinct again, as in your original code: only a nil slice skips a :if clause, while an empty non-nil slice keeps it and renders IN (NULL). For call sites where empty should mean "don't filter", the generated dynfilter.go now includes a NilableSlice helper that converts empty slices to nil. Tests and README have been updated to match, and this PR no longer changes any behavior of the original code.

No pressure either way: if you'd rather not take on SQLite/MySQL surface area in this repo, I completely understand, I'm happy to maintain this as a standalone fork instead (primarily for the SQLite support I need). I mostly wanted to offer the improvements back, and to say thanks for the plugin regardless, I really liked the idea!

AI Disclosure
I developed this with substantial help from coding agents (you'll see the co-author trailers on most commits). I directed, reviewed, and tested the work, but I want to be upfront about it so you can calibrate your review accordingly.

[vtuanjs]

Hi @orlandoc01
Thanks for the contribution! Overall, it looks good to me.

One thing about slices: whether we should skip an empty slice should depend on the use case. I don't think we should automatically skip it just because it's empty. sqlc can handle the data/empty/null cases for us.

In the use case layer, we should have a nilableSlice or nilableArray function to handle this explicitly.

[orlandoc01]

@vtuanjs I think you make a good point that we should treat nil different from an empty slice, and adding a NilableSlice function by default to get the behavior of skipping a clause when the slice is empty is also a good suggestion. I've revised the code as such and amended the top level PR body message to reflect that. Feel free to use if it helps and let me know if you have any more feedback to share!

[vtuanjs]

LGTM, thank @orlandoc01
Let me test it a bit more, and after that, I’ll release it.