Check the SQLite analyze cases against sqlite3 in goldeneye, and make sqlc agree with it

[kyleconroy]

The analyze cases under internal/endtoend/testdata were only checked against a real database for ClickHouse. This extends goldeneye's analysis check to SQLite, and fixes what the check found sqlc's analysis saying that SQLite does not.

The check

install sqlite builds one more shell, under analysis/, with SQLITE_ENABLE_COLUMN_METADATA and every extension option at once. The check asks it three things about each query and prints the answer in the shape sqlc analyze uses:

• Columns come from .stats stmt, which reports the table column each result column is read from; that column's declared type is the result column's, and its NOT NULL decides nullability, the rowid counting as NOT NULL.
• Expressions have no declared type in SQLite, so they are typed by the storage class of the value the query returns. The query runs over the case's fixture.sql with each parameter bound to a value of its own column, and again over no rows; a NULL from either run makes the column nullable, which catches aggregates over nothing and the far side of an outer join.
• Parameters are found in the bytecode EXPLAIN prints, the SQLite counterpart of ClickHouse's query tree. Each is followed from the register its Variable loads, through copies and expressions, to the first opcode that uses it against something nameable: a comparison operand, a rowid or index seek, an Insert record position, or the ephemeral table of an IN list. MustBeInt types a LIMIT parameter as an integer.

The query-file parsing, placeholder rewriting and the JSON output types move from the clickhouse package into endtoend, since both engines share them. A new analyze_expressions/sqlite case with a fixture covers aggregates, an IN list, LIMIT/OFFSET, a LEFT JOIN, a concatenated LIKE parameter and INSERT RETURNING. All five SQLite cases and the six ClickHouse ones match their database.

What the check found

• sum, abs, ceil, floor and trunc return an integer for an integer and a real for a real; the dialect widened them to real. They are now written the way PostgreSQL's catalog writes sum: once over any, returning the real a text or blob argument gets, and once per spelling types.jsonl gives integer and real, returning that type. The analysis core picks the overload whose parameter is the argument's type; the legacy compiler resolves by arity alone and takes the first, so what it generates is unchanged (the goldens are byte-for-byte what main produces).
• IS and IS NOT test for NULL rather than propagate it, so their result is never NULL; the core was marking x IS NULL nullable. SQLite's postfix ISNULL and NOTNULL, which arrive as operators with no right operand, are predicates too.
• LIKE, GLOB, REGEXP and MATCH were typed as text because the dialect listed them under PostgreSQL's ~~ spelling that the parser never uses. They are now in the dialect's comparison list under their real names.

One disagreement is left as is and documented in the README: SQLite stores a predicate such as x IS NULL as an integer, while sqlc types it boolean, which is what its generated code has always used.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PdKaVjSmdkmXPeUkxetyDY

---

Generated by Claude Code