Latest Results
fix: a constant null `Between` bound must not null already-false rows
`precondition` returned an all-null `ConstantArray` whenever either bound was
a constant null. Under Kleene `AND` a null bound only makes a row null when
the other comparison is not already false, so this nulled rows the surviving
bound had already falsified.
Because the branch keys off `as_constant()`, the result was also
encoding-dependent: an all-null chunk stored as a `PrimitiveArray` produced
`[false, null]` while the same chunk compressed to a `ConstantArray` produced
`[null, null]`. Compression encodes all-null chunks as constants, so the same
predicate over the same data could disagree from chunk to chunk.
This also made `find_between` non-value-preserving. It rewrites conjoined
comparisons with literal bounds into `Between`, so a null literal reached
`precondition` through the standard optimizer. Under `not(...)` the rewrite
changed a query's row count, since `NOT FALSE` is `TRUE` while `NOT UNKNOWN`
is `UNKNOWN`.
Short-circuit to all null only when both bounds are null, which is the one
case where no comparison can falsify a row. With a single null bound, desugar
into the two comparisons combined with Kleene `AND`, since the kernels all
require non-null constant bounds. Reuse that desugaring for the existing
fallback in `between_canonical`.
`test_constants` asserted only that no row was `true`, which held under both
the old and the correct result, so tighten it to the exact values.
Signed-off-by: "Connor" <connor@spiraldb.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Kc2AuwyEzVQBJLMbfVV36claude/github-issue-9212-ia0abi Latest Branches
+10%
claude/github-issue-9212-ia0abi -1%
+15%
ct/row-fn-spatial-predicates Ā© 2026 CodSpeed Technology