feat(python): Support shortcut eval of common boolean filters in SQL interface "WHERE" clause #18571
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #18373.
Update
WHERE TRUE
WHERE FALSE
WHERE 1 = 1
WHERE 1 != 0
This pattern is a bit odd-looking, but often arises from programmatic query builders that want to append to a WHERE clause without having to check if a new filter is the first (so they can always "AND" it onto the existing clause). As a result a query may always contain "WHERE 1=1" (or equivalent), with the expectation that it is optimised out.
When the SQL parser sees that a WHERE clause represents such a pattern it now skips frame filtering entirely, immediately returning the same frame (if TRUE) or an empty frame with an identical schema (if FALSE).
(Note: you usually see the "TRUE" version of this, but once in a blue moon you'll see something evaluating to "FALSE" as some query-building optimisers may generate this if they can evaluate the truth-value of a constraint clause before it hits the backend).
Also
Minor internal module cleanup/refactor:
sql_expr.rs
to newtypes.rs
.Examples