QuakeWang commented on code in PR #496:
URL: https://github.com/apache/paimon-rust/pull/496#discussion_r3563849008
##########
crates/integrations/datafusion/src/filter_pushdown.rs:
##########
@@ -81,22 +89,34 @@ pub(crate) fn analyze_filters(filters: &[Expr], fields:
&[DataField]) -> FilterP
#[cfg(test)]
pub(crate) fn build_pushed_predicate(filters: &[Expr], fields: &[DataField])
-> Option<Predicate> {
- analyze_filters(filters, fields).pushed_predicate
+ analyze_filters(filters, fields, true).pushed_predicate
}
pub(crate) fn classify_filter_pushdown<F>(
filter: &Expr,
fields: &[DataField],
+ case_sensitive: bool,
is_exact_filter_pushdown: F,
) -> TableProviderFilterPushDown
where
F: Fn(&Predicate) -> bool,
{
- let translator = FilterTranslator::new(fields);
+ // `FilterTranslator` still supports case-insensitive column resolution for
+ // direct ReadBuilder API callers (and its own unit tests), but the
DataFusion
+ // TableProvider/SQL path always passes `case_sensitive = true`: the
planner
+ // resolves columns against the schema before `scan`, so SQL reads are
+ // case-sensitive. Reporting `Exact` tells DataFusion to drop its residual
+ // filter, so it must only be returned when column resolution is
unambiguous.
+ // The `Inexact` cap for schemas with ASCII case-folding collisions (e.g.
+ // `Name`/`name`) is a conservative guard: if a reference were ever
resolved
+ // case-insensitively, `Exact` would have dropped the residual while the
+ // translation pushed nothing — filtering neither side. Keep the residual.
+ let allow_exact = !has_ascii_case_collision(fields);
Review Comment:
DataFusion now always uses `case_sensitive = true`, but this guard still
downgrades every otherwise `Exact` filter to `Inexact` whenever any two schema
fields differ only by case. For example, a filter on `pt` becomes `Inexact`
solely because unrelated `Name` / `name` fields exist.
##########
bindings/c/src/table.rs:
##########
@@ -157,6 +167,26 @@ pub unsafe extern "C" fn
paimon_read_builder_with_projection(
std::ptr::null_mut()
}
+/// Set whether column-name matching (projection and predicate resolution) is
Review Comment:
This setting does not control predicate resolution. Predicates are resolved
earlier by the separate predicate constructors, so setting this to `false`
alone only affects projection matching.
--
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]
