fallintoplace opened a new issue, #2490:
URL: https://github.com/apache/iceberg-rust/issues/2490
`TableScanBuilder::with_case_sensitive(false)` does not appear to be honored
when the scan filter is bound.
What I found
- `TableScanBuilder::with_case_sensitive` stores the flag on the builder in
`crates/iceberg/src/scan/mod.rs`
- `build()` later binds the scan predicate with `true` instead of the
configured flag
- that bound predicate is then used for file metrics pruning in
`process_data_manifest_entry`
Relevant code
- `crates/iceberg/src/scan/mod.rs:93`
- `crates/iceberg/src/scan/mod.rs:278`
- `crates/iceberg/src/scan/mod.rs:529`
Why this looks wrong
A scan configured with `with_case_sensitive(false)` should allow
case-insensitive field resolution consistently across planning. Right now,
filters are effectively bound case-sensitively during scan construction.
Expected behavior
A filter like `Reference("ID") == ...` should bind successfully against a
schema field named `id` when the scan was configured with
`with_case_sensitive(false)`.
Actual behavior
The filter is bound as if case sensitivity were still enabled, because
`build()` hardcodes `true` during binding:
```rust
let snapshot_bound_predicate = if let Some(ref predicates) = self.filter {
Some(predicates.bind(schema.clone(), true)?)
} else {
None
};
```
There is also a smaller related gap in the same method: when the table has
no current snapshot, `build()` returns early before binding the filter at all,
so malformed filters can be skipped on empty tables. But the main issue here is
the incorrect case-sensitivity handling on normal scans.
I did not find an obvious existing issue for this in a quick tracker search.
--
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]
