[TimelordUK]

R13 slice 4, second part: WHERE's comparison operators (=, <>, !=, <, <=, >, >=) now go through the value evaluator and are converted back to a WHERE truth value once, in evaluate_delegated. Comparisons with a legacy method call on the left (Length(), IndexOf(), Trim*()) keep WHERE's path until slice 5.

Closes P54: a large integer literal matched the wrong row in WHERE

WHERE read every number literal through f64, which can't hold every integer above 2^53. So WHERE id = 9007199254740993 returned the row with id 9007199254740992, a different record, not an empty result. On that same row SELECT id = 9007199254740993 said false, so the query contradicted itself. The value evaluator reads i64 first and was already right.

Commits

1. Pins. A new DuckDB-generated matrix (EXPECTED_OPERANDS) for the cases where the two evaluators turn a literal into different values. It records four wrong WHERE answers (three for P54, plus '5.0' = 5.0). Also adds the corpus case where_big_int_literal_equals (DIFFER) with an IN control, and data/big_ids.csv. Files P53: '5.0' = 5 compares as text in both evaluators, where DuckDB casts the string to a number. It's low priority and has no corpus case; the entry explains why.
2. DATETIME() in local time. WHERE took today's date from local time, the value evaluator from UTC, so they disagreed between 00:00 and 01:00 under BST. WHERE was right (DuckDB's current_date uses the session time zone, local by default), so the value evaluator changed before the switch-over. This is the one step without a failing test first: the two only disagree during that hour.
3. Switch over. Exactly the four pinned answers changed; the P53 pair and every other matrix entry held. Parity moved by exactly one case: 175 → 176 AGREE / 206. evaluate_binary_op now receives the whole expression node, so nothing rebuilds and clones it on each row.
4. Docs. R13 entry, P53/P54 entries, and updated fix-order table and headline counts.

Things this turned up

• Part 1 (refactor(r13): WHERE BETWEEN / IN delegate to the value evaluator (R13 slice 4, part 1) #87) wasn't quite a no-op. Routing IN and BETWEEN through the value evaluator also switched them to its literal reader, which fixed P54 for those two operators. The parity report couldn't show it because no case held an integer that large.
• Harness blind spot. The harness compares numbers as floats, so both ids render as 9007199254740992.0 and only the name column showed the wrong row. A case that selects only a large integer can't tell two ids apart. This is noted in the corpus case and in P54.

Verification

• Parity --check holds (206 cases). Reports compared against a saved baseline at each commit: the only change was the P54 case.
• Evaluator matrix green, all three sets.
• ./run_all_tests.sh green: Rust, 572 Python tests, all FORMAL examples. The one SMOKE failure (expander_rewriters query 7) also fails on main.
• Over trades_100000.csv (~2.4 s of which is loading the CSV): WHERE price + 0 > quantity 3.0 s → 2.5 s; the other WHERE shapes are unchanged.

Next (slice 4 part 3)

LIKE: WHERE uses a regex cache, and the two evaluators disagree on a non-string operand (5.0 LIKE '5%' is FALSE in WHERE, TRUE in the value evaluator, an error in DuckDB), so that needs a decision first. Then IS NULL. AND/OR/NOT/CASE wait on slice 5.

🤖 Generated with Claude Code