nsivabalan commented on code in PR #20458:
URL: https://github.com/apache/hudi/pull/20458#discussion_r4460923444


##########
hudi-spark-datasource/hudi-spark-common/src/main/scala/org/apache/spark/sql/HoodieSparkTypeUtils.scala:
##########
@@ -37,16 +37,29 @@ object HoodieSparkTypeUtils {
   def isCastPreservingOrdering(from: DataType, to: DataType): Boolean =
     (from, to) match {
       // NOTE: Casting between String and Numeric types re-orders elements 
(for ex, "10" < "9"
-      //       lexicographically)
-      case (StringType, _: NumericType) => false
-      case (_: NumericType, StringType) => false
+      //       lexicographically). These match by type, so that collated 
strings on Spark 4 are
+      //       rejected as well
+      case (_: StringType, _: NumericType) => false
+      case (_: NumericType, _: StringType) => false
       // NOTE: Timestamps format in the session time zone, so local time 
repeats across a DST
       //       fall-back (for ex, 01:30 EDT is followed by 01:10 EST) and the 
strings re-order
-      case (TimestampType, StringType) => false
+      case (TimestampType, _: StringType) => false
+      // NOTE: On Spark 4 StringType carries a collation, and casting to a 
different collation changes
+      //       the sort order (for ex, "B" < "a" in UTF8_BINARY but "a" < "B" 
in UTF8_LCASE). Equality
+      //       also compares the char/varchar length constraint, so those 
casts are conservatively
+      //       rejected too. On Spark 3 StringType is a singleton, making this 
arm trivially true
+      case (fromStr: StringType, toStr: StringType) => fromStr == toStr

Review Comment:
   This covers a collation introduced by a cast. What about a column declared 
`STRING COLLATE UTF8_LCASE` and filtered with no cast, e.g. `col = 'a'`? I 
don't see collation handling anywhere in data skipping, so I'd expect the 
column stats bounds to be computed in byte order, while the index's min/max 
columns take the table schema's collated type and get compared under 
`UTF8_LCASE`. That would give the same wrong pruning as the repro here. Traced 
from source, not run. If it holds, it needs a follow-up issue (or skipping data 
skipping for columns with a non-default collation).



-- 
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]

Reply via email to