kumarUjjawal commented on code in PR #19926:
URL: https://github.com/apache/datafusion/pull/19926#discussion_r2724248308
##########
datafusion/functions/src/math/round.rs:
##########
@@ -117,15 +209,135 @@ impl ScalarUDFImpl for RoundFunc {
&self.signature
}
- fn return_type(&self, arg_types: &[DataType]) -> Result<DataType> {
- Ok(match arg_types[0].clone() {
+ fn return_field_from_args(&self, args: ReturnFieldArgs) ->
Result<FieldRef> {
+ let input_field = &args.arg_fields[0];
+ let input_type = input_field.data_type();
+
+ // Get decimal_places from scalar_arguments
+ // If dp is not a constant scalar, we must keep the original scale
because
+ // we can't determine a single output scale for varying per-row dp
values.
+ let (decimal_places, dp_is_scalar) = match
args.scalar_arguments.get(1) {
+ None => (0, true), // No dp argument means default to 0
+ Some(None) => (0, false), // dp is a column
+ Some(Some(ScalarValue::Int32(Some(v)))) => (*v, true),
+ Some(Some(ScalarValue::Int64(Some(v)))) => {
Review Comment:
Yes, `ReturnFieldArgs.scalar_arguments` are taken directly from the original
`Expr::Literal` values, so they can be `ScalarValue::Int64` even though the
function signature/coercion will ensure the argument is evaluated as Int32 at
runtime.
Type coercion is applied when building the physical expression / evaluating
the arguments, but scalar_arguments is just “what literal was written in the
query”, not the coerced value. That’s why we handle Int64 there: to (a) treat
it as a constant dp for return-type computation and (b) produce a clear
out-of-range error for literals that can’t fit in i32.
--
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]
