What do you want to change?
Problem
Plugins receive Query.columns[].table which only covers tables contributing
to SELECT output. Tables referenced only in subqueries, CTEs, or JOINs are
invisible to plugins.
Example — plugin only sees accounts, misses account_tags and transactions:
-- name: ListSpaceAccounts :many
WITH filtered_accounts AS (
SELECT account_id FROM accounts WHERE space_id = ?
AND NOT EXISTS (
SELECT 1 FROM account_tags t WHERE t.account_id = accounts.account_id
)
)
SELECT acc.* FROM accounts acc
JOIN filtered_accounts fa ON acc.account_id = fa.account_id
LEFT JOIN transactions t ON t.debit_account_id = acc.account_id
Use case
SQLite's update_hook fires with the name of the written table. Frontend plugins
generating reactive query stores need every table a query depends on — not just
output columns — to know when to refetch. Currently the only workaround is running
sqlc parse as a separate post-codegen script outside the plugin WASM sandbox.
Proposed change
Add source_tables to the Query proto:
message Query {
// ... existing fields ...
repeated string source_tables = 7; // all tables this query reads from, CTEs excluded
}
sqlc's analyzer already resolves this internally when validating joins and column
references — this only surfaces existing data through the proto, no new analysis needed.
Expected result
source_tables: ["account_tags", "accounts", "transactions"]
Alternatives considered
| Approach |
Problem |
| Regex on Query.text inside plugin |
Fragile, false positives |
| sqlc parse as post-codegen script |
Can't run from inside WASM sandbox |
| Column.table from output columns |
Misses subquery/CTE/JOIN-only dependencies |
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response
What do you want to change?
Problem
Plugins receive Query.columns[].table which only covers tables contributing
to SELECT output. Tables referenced only in subqueries, CTEs, or JOINs are
invisible to plugins.
Example — plugin only sees accounts, misses account_tags and transactions:
Use case
SQLite's update_hook fires with the name of the written table. Frontend plugins
generating reactive query stores need every table a query depends on — not just
output columns — to know when to refetch. Currently the only workaround is running
sqlc parse as a separate post-codegen script outside the plugin WASM sandbox.
Proposed change
Add source_tables to the Query proto:
sqlc's analyzer already resolves this internally when validating joins and column
references — this only surfaces existing data through the proto, no new analysis needed.
Expected result
Alternatives considered
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response