Split out of #224 planning.
Problem
All existing test functions in storage/search/lucene are string assertions — they compare the rendered SQL against an expected string. None execute it. That is structurally why #224 survived: "tags" = ? was exactly the string the code intended to produce, so a string test passes while Postgres rejects the query at runtime.
The #224 fix adds executed-SQL tests, but against in-process SQLite. SQLite exercises the json_each paths, which were never broken. The genuinely risky rendering is Postgres-specific — the @> operator, unnest, and how Postgres resolves array operators against bound parameters — and it stays string-asserted.
Concrete example of what string assertions cannot catch, found during #224 review: int[] @> ARRAY[$1] fails with operator does not exist: integer[] @> text[] when the parameter is bound as text. Only an executed query reveals it.
.github/workflows/ci.yml currently runs bare go test ./... with no database services.
Suggested fix
Add a services: postgres: block to the CI test job and gate the executed assertions on POSTGRES_DSN, so local runs stay fast and hermetic while CI proves the SQL executes.
Why deferred
Would be the first database service in a pipeline that has none. Accepted as a known coverage gap during #224 review rather than overlooked.
Depends on #224 landing first, since it would run the tests introduced there.
Split out of #224 planning.
Problem
All existing test functions in
storage/search/luceneare string assertions — they compare the rendered SQL against an expected string. None execute it. That is structurally why #224 survived:"tags" = ?was exactly the string the code intended to produce, so a string test passes while Postgres rejects the query at runtime.The #224 fix adds executed-SQL tests, but against in-process SQLite. SQLite exercises the
json_eachpaths, which were never broken. The genuinely risky rendering is Postgres-specific — the@>operator,unnest, and how Postgres resolves array operators against bound parameters — and it stays string-asserted.Concrete example of what string assertions cannot catch, found during #224 review:
int[] @> ARRAY[$1]fails withoperator does not exist: integer[] @> text[]when the parameter is bound as text. Only an executed query reveals it..github/workflows/ci.ymlcurrently runs barego test ./...with no database services.Suggested fix
Add a
services: postgres:block to the CI test job and gate the executed assertions onPOSTGRES_DSN, so local runs stay fast and hermetic while CI proves the SQL executes.Why deferred
Would be the first database service in a pipeline that has none. Accepted as a known coverage gap during #224 review rather than overlooked.
Depends on #224 landing first, since it would run the tests introduced there.