sunchao commented on code in PR #5359:
URL: https://github.com/apache/datafusion-comet/pull/5359#discussion_r3788483988
##########
spark/src/main/scala/org/apache/comet/serde/CometScalarFunction.scala:
##########
@@ -21,14 +21,53 @@ package org.apache.comet.serde
import org.apache.spark.sql.catalyst.expressions.{Attribute, Expression}
+import org.apache.comet.CometSparkSessionExtensions.withFallbackReason
import org.apache.comet.serde.ExprOuterClass.Expr
import org.apache.comet.serde.QueryPlanSerde.{exprToProtoInternal,
scalarFunctionExprToProto}
/** Serde for scalar function. */
case class CometScalarFunction[T <: Expression](name: String) extends
CometExpressionSerde[T] {
override def convert(expr: T, inputs: Seq[Attribute], binding: Boolean):
Option[Expr] = {
+ if (CometScalarFunction.isAnsiSensitive(expr)) {
+ withFallbackReason(
+ expr,
+ s"${expr.nodeName} carries failOnError/evalMode/nullOnOverflow and
cannot use " +
+ s"CometScalarFunction('$name'). Prefer name-based ANSI/try variants
" +
+ "(e.g. parse_url / try_parse_url), or a custom serde with " +
+ "scalarFunctionExprToProtoWithReturnType plus a native match arm
that " +
+ "consumes fail_on_error.")
+ return None
+ }
val childExpr = expr.children.map(exprToProtoInternal(_, inputs, binding))
val optExpr = scalarFunctionExprToProto(name, childExpr: _*)
optExpr
}
}
+
+object CometScalarFunction {
+
+ /** Product field names that indicate ANSI / eval-mode sensitive Spark
expressions. */
+ private val AnsiSensitiveFields: Set[String] =
+ Set("failOnError", "evalMode", "nullOnOverflow")
Review Comment:
[P2] Recognize `ansiEnabled` and Spark 4.1+ `evalContext`
Could we include `ansiEnabled` and `evalContext` in `AnsiSensitiveFields`?
Spark `Round`, `BRound`, and `Conv` store ANSI behavior in `ansiEnabled`, while
Spark 4.1+ `Add`, `Subtract`, `Multiply`, `Divide`, and related arithmetic
expressions store `NumericEvalContext` as `evalContext` and expose `evalMode`
only through an inherited method. Neither marker is present in this set, so
both `isAnsiSensitive(expr)` and `isAnsiSensitive(clazz)` return false. A plain
`CometScalarFunction` registration can therefore silently serialize
`fail_on_error=false` and still pass the registration audit. The current
handlers for these expressions are specialized, so this is a gap in the
proposed safeguard rather than a regression in existing registrations. Could we
recognize both fields and add regression coverage using real Spark `Round` and
Spark 4.1+ `Add` expressions?
--
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]
