wombatu-kun commented on code in PR #19475:
URL: https://github.com/apache/hudi/pull/19475#discussion_r4214154083


##########
hudi-spark-datasource/hudi-spark-common/src/main/scala/org/apache/spark/sql/HoodieSparkTypeUtils.scala:
##########
@@ -35,10 +36,20 @@ object HoodieSparkTypeUtils {
    */
   def isCastPreservingOrdering(from: DataType, to: DataType): Boolean =
     (from, to) match {
-      // NOTE: In the casting rules defined by Spark, only casting from String 
to Numeric
-      // (and vice versa) are the only casts that might break the ordering of 
the elements after casting
-      case (StringType, _: NumericType) => false
-      case (_: NumericType, StringType) => false
+      // NOTE: Casting between String and Numeric types re-orders elements 
(for ex, "10" < "9"
+      //       lexicographically). These arms must stay ahead of the numeric 
arm below, since
+      //       Cast.canUpCast treats atomic-to-string casts as legal up-casts
+      case (_: StringType, _: NumericType) => false
+      case (_: NumericType, _: StringType) => false
+      // NOTE: On Spark 4 StringType carries a collation (and constraint) and 
its equals compares
+      //       both; casting to a different collation changes the sort order. 
On Spark 3
+      //       StringType is a singleton, making this arm trivially true
+      case (fromStr: StringType, toStr: StringType) => fromStr == toStr
+      // NOTE: Narrowing numeric casts (for ex, bigint to int) overflow and 
wrap around in
+      //       non-ANSI mode, breaking ordering; only up-casts are guaranteed 
order-preserving.
+      //       This is conservative (for ex, double to float rounds 
monotonically but is
+      //       rejected), which only costs pruning opportunity, never 
correctness
+      case (fromNum: NumericType, toNum: NumericType) => 
Cast.canUpCast(fromNum, toNum)

Review Comment:
   This also rejects decimal -> double/float, the cast Spark's 
`DecimalPrecision` coercion puts on a decimal column compared with a double 
(e.g. PySpark `df.price > 99.5`), so those filters stop pruning even though the 
cast is as monotonic as the long -> float one accepted here. Is that intended, 
or should `DecimalType` -> `FloatType`/`DoubleType` be allowed explicitly ahead 
of this arm?



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