Skip to content

fix(parity): resolve every WHERE operand through one path (P46) #80

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
TimelordUK merged 3 commits into from
Sep 13, 2026
Merged

fix(parity): resolve every WHERE operand through one path (P46) #80

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e5f9a89
test(parity): pin every site of the P46 right-hand-operand hole
TimelordUK Sep 13, 2026
1512523
fix(parity): resolve every WHERE operand through one path (P46)
TimelordUK Sep 13, 2026
f061d12
docs(parity): close P46, file P49, decouple P48
TimelordUK Sep 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/ENGINE_REFACTORING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -176,6 +176,7 @@ feature work**, and so we can tell the difference between "this is awkward" and
| [P15](SQL_PARITY.md) | An inline window function in `QUALIFY` is never lifted (the lifter walks the SELECT list only) → `Expected column name, got: WindowFunction` | hard error |
| *(fixed, PR #33)* | `ILIKE` inside `OVER (ORDER BY ...)` left unrewritten, reaching the executor as an unknown operator | hard error |
| *(fixed, PR #33)* | `INTO` inside `(a, b) IN (SELECT ...)` never removed | reaches executor |
| *(fixed 2026-09-13)* [P46](SQL_PARITY.md#p46) | The WHERE evaluator's literal reader ended `_ => Ok(Null)`, so every column, `CASE` or expression on the right of a comparison, in an `IN` list or as a `BETWEEN` bound read as NULL — **zero rows, no error**. Not a walker, but the same catch-all shape one layer down: the arm that should have been a compile-time gap was a value | **wrong results, no error** |

P9 is the one that matters most: `HAVING COUNT(*) BETWEEN 1 AND 2` returned
4 rows where DuckDB returns 1, with no error. A catch-all turned a missing
Expand Down
Loading
Loading