jackylee-ch opened a new pull request, #3917:
URL: https://github.com/apache/iceberg-python/pull/3917
# Rationale for this change
The `BooleanLiteral` to `AlwaysTrue`/`AlwaysFalse` conversion is attached
only to the whole expression, so a bare boolean used as an operand reaches
`And`/`Or`/`Not` as a `BooleanLiteral` and fails pydantic validation. The two
spellings of the same filter disagree:
```python
parse("(false) or foo = 1") # EqualTo(foo, 1)
parse("false or foo = 1") # ValidationError: 1 validation error for Or
```
Seeding a filter with `true` and appending clauses is a common way to build
one, so `row_filter="true and status = 'x'"` raises instead of scanning.
`And.__new__`/`Or.__new__` already absorb `AlwaysTrue`/`AlwaysFalse` operands,
which is why the parenthesized form works.
`predicate` now gets its own copy of the boolean element that folds to
`AlwaysTrue`/`AlwaysFalse`. The copy matters: `literal` and `literal_set` share
the same element and need the raw `BooleanLiteral`.
## Are these changes tested?
Yes, `test_boolean_as_operand` covers `and`/`or`/`not` in both positions,
and `test_boolean_as_literal_is_unchanged` pins `foo = true` and `foo in (true,
false)`. The seven operand cases fail without the change; the literal case
passes either way.
## Are there any user-facing changes?
Filters using a bare `true`/`false` as an operand parse instead of raising.
--
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]
