Fix invalid SQL for column-level CHECK constraints using range/BETWEEN expressions

[vjymisal0]

Summary

Fixes #1056.

Column-level CHECK constraints built from a range pattern (e.g. t.column(type, check: 0...26 ~= type)) generate invalid SQL and SQLite rejects the CREATE TABLE statement with a syntax error, exactly as reported in #1056:

near ""type"": syntax error in "CREATE TABLE "Observations" (..., "type" INTEGER NOT NULL CHECK "type" BETWEEN 0 AND 26)"

Root cause

Every comparison operator (>, <, ==, >=, etc.) self-wraps its generated SQL in parentheses via Operator.infix(...) (see Sources/SQLite/Typed/Operators.swift), e.g. column > 0 compiles to ("column" > 0).

The ~= operator overloads used for Range/ClosedRange/PartialRange... pattern matching (Sources/SQLite/Typed/Operators.swift:560-599) are the one exception — they build their BETWEEN/comparison SQL fragment directly without wrapping it in parens.

This is harmless when the expression is used standalone (e.g. .filter(0...26 ~= type)), but it breaks when used as a column-level CHECK constraint. Schema.swift's per-column definition() builds the CHECK clause as "CHECK" + " " + check (Sources/SQLite/Typed/Schema.swift:578), relying on the passed-in expression already being parenthesized — which holds for every other comparator, but not for the un-wrapped BETWEEN/range output. (The table-level check() builder in Schema.swift:438 doesn't hit this because it uses "CHECK".prefix(condition), which unconditionally adds its own parens — that's why the issue reporter found "table checks" worked around the bug.)

Fix

Wrap the SQL generated by all 10 ~= overloads (ClosedRange, Range, PartialRangeThrough, PartialRangeUpTo, PartialRangeFrom, each with an optional-column variant) in parentheses, matching the convention every other comparison operator already follows. This makes range-based conditions self-contained/composable like the rest of the operator library, and fixes the column-level CHECK bug without touching Schema.swift at all.

Testing

• Updated the existing BETWEEN/range operator tests in Tests/SQLiteTests/Typed/OperatorsTests.swift to expect the now-parenthesized output (purely a string-format change; the underlying SQL semantics/bindings are unchanged since parens don't alter meaning in these positions).
• Added test_column_withRangeCheck_compilesValidCheckConstraint in Tests/SQLiteTests/Schema/SchemaTests.swift, which reproduces the exact column-level CHECK scenario from Column check constraints generate a syntax error #1056 and asserts the generated CREATE TABLE statement is now well-formed: CREATE TABLE "table" ("int64" INTEGER NOT NULL CHECK ("int64" BETWEEN 0 AND 26)).
• I don't have a Swift toolchain available in my current environment to run swift test directly, so I traced the fix end-to-end through the Operator.infix/.wrap/.prefix helpers, the ~= overloads, and Schema.swift's definition()/check() to confirm the generated string exactly matches the new test expectations (including that non-optional/optional variants and the standalone table-level check() path are unaffected). Would appreciate CI running the updated suite.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vjymisal0]

Pushed a fix setting TUIST_USE_SWIFTERPM: '0' in .github/workflows/build.yml to resolve the Tuist CI failure (Path not found: .../Tuist/Package.resolved) on the macOS runner.

[jberkel]

i believe this is no longer necessary now, fixed in 08a2b63

[vjymisal0]

Removed the redundant TUIST_USE_SWIFTERPM environment variable in 93061d6. Thanks!

[vjymisal0]

The remaining red checks are macOS build jobs from CI. I don't have a macOS runner locally on this machine, so I can't reproduce those here; happy to adjust if someone can share the failing compiler/test output from the job.

[jberkel]

don't worry, that's been around for some time, it looks like some undefined behavior introduced in one of the recently merged PRs, i'll investigate

[jberkel]

that crash is probably the one you submitted a fix for in #1373? that PR is missing a detailed description, it looks like the issue is that the deinit() now defers to a queue and introduces a race condition? (although it's synchronous) or that it actually throws an error if the connection cannot be closed? (although that's handled with try?)

[vjymisal0]

Hi @jberkel, thank you for following up!

To clarify the rationale behind #1373:
In SQLite C API semantics, calling sqlite3_close() (as close() does) returns SQLITE_BUSY if there are any unfinalized prepared statements or active backup objects still referencing the db connection. When deinit executed ry? close(), the busy error was discarded and the connection was never closed. Subsequent operations or tear-down of those lingering statements could lead to undefined behavior or crashes.

In contrast, sqlite3_close_v2(handle) is specifically designed by SQLite for reference-counted / GC environments:

1. If no statements are open, it closes immediately.
2. If statements or backups are still active, it marks the connection as a 'zombie' and automatically releases the connection's resources as soon as the last statement is finalized.
3. Calling sqlite3_close_v2 directly avoids dispatching to queue.sync during deinit, preventing any re-entrancy or deadlock risks when deallocating on arbitrary threads.

I've also updated the description on #1373 to reflect this context. Let me know what you think!

[jberkel]

Ok, that's much clearer, I missed the _v2 bit on the PR. Let's see if it fixes the build.

[jberkel]

No, but it only seems to fail on macos-15, perhaps it's related to something in that runner.

[vjymisal0]

Thanks for looking into this, @jberkel! I have rebased this branch cleanly onto latest upstream master to pick up the recent CI updates and disable-macos-15 fix.