Add SQL Server, Spanner and DuckDB to goldeneye: generate their dialects and check the analyze cases against live databases

[kyleconroy]

Summary

Three more engines get goldeneye's two checks: their generated dialect files are verified byte for byte against a live database, and their analyze_* cases are verified against what the database itself reports.

• SQL Server (mssql, MSSQL_SERVER_URI, the mcr.microsoft.com/mssql/server:2025-latest image). relations.jsonl is every view of sys and INFORMATION_SCHEMA, each described by sys.dm_exec_describe_first_result_set from a scratch user database, since master lists internal views no query can name. The analyze check describes each query without running it: result columns from the same DMV, parameter types from sp_describe_undeclared_parameters, and the column a parameter is compared with or assigned to from the estimated XML showplan compiled with the parameters declared as those types. Spellings types.jsonl lists as aliases (numeric, timestamp) are reported by the dialect's name (decimal, rowversion).
• Spanner (spanner, SPANNER_SERVER_URI, the us-docker.pkg.dev/spanner-omni/images/spanner-omni:2026.r2.1-beta image, writing into the googlesql dialect). relations.jsonl is every view of INFORMATION_SCHEMA and SPANNER_SYS. The analyze check creates a database per case with the schema as DDL, writes the fixture, compiles each query in PLAN mode (DML in a rolled-back read-write transaction), and reads columns and parameter types from the result metadata and provenance from the query plan: Serialize Result lists the outputs, Scan nodes name table columns, comparisons show up as ($col = @param), and a DML plan lists its THEN RETURN outputs before the written values.
• DuckDB (duckdb). 2.0 has no release yet, so install duckdb downloads the current build of DuckDB's v2.0 preview channel (a rolling tarball; nothing can be pinned, duckdb.GeneratedFrom records the build the dialect came from) into the user cache directory, where Locate finds it after DUCKDB and before PATH. The dialect is regenerated from that build, which adds 21 functions. The new analyze check drives the CLI: parameter types from EXPLAIN (FORMAT json) EXECUTE with a string sentinel bound to each parameter, result types from DESCRIBE with a typed NULL in each parameter's place, provenance from the query text resolved against duckdb_columns() (DuckDB prints plans with bare column names and describes no DML), and expression nullability by running the query with a value of each parameter's type over the fixture and over no rows.

Each engine gets a gen.yml job, a docker-compose.yml service where a server is needed, tests that skip without a database, and a README section describing what the database says and what it keeps to itself.

What the checks found

• A rowversion or sysname column is NOT NULL unless declared nullable; the SQL Server converter now does that.
• SQL Server rejects CAST to an alias type and = on vector values, and its describe function calls every computed column nullable. analyze_types/mssql now casts nullable columns and moves the parameter casts into the WHERE clause; its golden is regenerated.
• Spanner requires STRING(MAX) and rejects NUMERIC(p,s), BIGNUMERIC, GEOGRAPHY, INTERVAL and STRUCT columns, and cannot return a STRUCT as a column. The three simple GoogleSQL cases get STRING(MAX); the BigQuery-flavoured types case is kept intact as analyze_types/bigquery, which the Spanner check does not read, beside a Spanner-valid analyze_types/googlesql.
• SPANNER_SYS has a PROTO column, so the GoogleSQL types.jsonl gains a proto type.
• The new DuckDB build lists each type alias once per schema it is visible in; the generator folds them.

The last commit fixes what an adversarial review of the three packages found (Spanner's DML output order and a nil Close, DuckDB's conversion-error matching and cast-type reading, SQL Server's ? numbering and block-aware statement splitting, among others).

Testing

• go test ./... in internal/goldeneye against a live SQL Server 2025, Spanner Omni 2026.r2.1 and DuckDB v2.0.0-alpha41396: the three dialects match, and all 17 analyze cases (8 MSSQL, 4 GoogleSQL, 5 DuckDB) match byte for byte.
• TestReplay/base for every case in the main module passes.
• The gen.yml jobs themselves were not exercised.

Known limits

• Spanner reports nothing about the nullability of an expression, so the Spanner check reports an expression as not null.
• Spanner's view names are kept in upper case; Spanner matches any case, but sqlc's GoogleSQL engine matches names as spelled.
• The DuckDB gen job goes red whenever the preview channel moves past the recorded build, which is the intended signal until 2.0 is released and can be pinned with a checksum.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F7cPsawATXMfiYqWg8nBVb

---

Generated by Claude Code