jackylee-ch opened a new pull request, #3916:
URL: https://github.com/apache/iceberg-python/pull/3916
# Rationale for this change
`SetPredicate.bind` keeps the result of `Literal.to(field_type)` for every
literal. For a value outside the field's range that result is the
`AboveMax`/`BelowMin` sentinel, whose value is the type's max/min, so the bound
set ends up holding a literal the user never wrote.
On an `int` column:
```python
In("id", [1, 2**40]).bind(schema) # BoundIn(..., {1, 2147483647})
NotIn("id", [1, 2**40]).bind(schema) # BoundNotIn(..., {1, 2147483647})
```
so `id in (1, 2**40)` matches rows where `id` is 2147483647, and the `not
in` form drops them.
`LiteralPredicate.bind` already folds these sentinels, which is why
`EqualTo("id", 2**40).bind(schema)` is `AlwaysFalse()` and `NotEqualTo` is
`AlwaysTrue()`. Java's `UnboundPredicate.bindInOperation` filters them out of
the set. Do the same here; an empty set after filtering is already folded by
`BoundIn`/`BoundNotIn`.
## Are these changes tested?
Yes, `test_above_int_bounds_in` and `test_below_int_bounds_in` in
`tests/expressions/test_evaluator.py`. They assert both the bound form and that
`expression_evaluator` no longer matches the clamped value. Both fail without
the change.
## Are there any user-facing changes?
`IN`/`NOT IN` with a literal outside the column's range no longer matches or
excludes rows at the range boundary.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
