You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7ced0ac
Browse filesBrowse the repository at this point in the historyBrowse files
## Which issue does this PR close?
Part of GreptimeTeam/greptimedb#8214.
Follow-up / smaller alternative to #21908. So this quick fix is for fix
a very common path, the rest(and the allow list version still lays in
#21908 and need more discussion)
- closes#22142
## Rationale for this change
`unwrap_cast` can currently rewrite predicates like:
```sql
CAST(ts_ns AS timestamp(3)) = timestamp(3) '2024-01-01 00:00:00.001'
```
into an equality against the original nanosecond column. That is not
equivalent: the original predicate matches every nanosecond timestamp
within the same millisecond, while the rewritten predicate only matches
the exact millisecond boundary.
## What changes are included in this PR?
This is intentionally a small blocklist-only fix:
- add a shared `is_timestamp_precision_narrowing_cast` helper
- block comparison cast unwrap when a timestamp cast narrows precision
- apply the same guard to logical and physical unwrap-cast simplifiers
- keep timestamp precision widening unwraps enabled
## Are these changes tested?
Added targeted logical, physical, and helper tests.
Ran:
```text
cargo test -p datafusion-optimizer unwrap_cast
cargo test -p datafusion-physical-expr unwrap_cast
cargo test -p datafusion-expr-common test_timestamp_precision_narrowing_cast
```
## Are there any user-facing changes?
Plans will keep timestamp precision-narrowing casts in comparison
predicates instead of unwrapping them incorrectly.
---------
Signed-off-by: discord9 <discord9@163.com>
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
0 commit comments