jiayuasu commented on code in PR #1194:
URL: https://github.com/apache/sedona-db/pull/1194#discussion_r3869842731
##########
rust/sedona-schema/src/matchers.rs:
##########
@@ -383,6 +402,32 @@ impl TypeMatcher for IsItemCrs {
}
}
+#[derive(Debug)]
+struct IsItemCrsOf {
+ item_matcher: Arc<dyn TypeMatcher + Send + Sync>,
+}
+
+impl TypeMatcher for IsItemCrsOf {
+ fn match_type(&self, arg: &SedonaType) -> bool {
+ if !arg.is_item_crs() {
Review Comment:
[P2] Could we validate the `crs` field as part of this matcher too?
`is_item_crs()` only checks field names, so `struct<item: geoarrow.wkb/binary,
crs: Utf8>` passes here even though all four kernels assume `Utf8View`. I
reproduced this from a Parquet column with that schema: `ST_SRID`, `ST_AsEWKB`,
and `ST_GeoHash` fail with internal StringView downcast errors, while `ST_CRS`
hits the DataFusion assertion that it returned `Utf8` after promising
`Utf8View`. I know the PR description calls this a separate gap, but it looks
like the same false-positive class at the new input-matcher boundary. Maybe
`SedonaType::is_item_crs()` should also require `fields[1].data_type() ==
DataType::Utf8View`, with `Utf8` and `Int64` CRS-field cases.
--
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]
