https://issues.apache.org/jira/browse/ARROW-12074

Please extract the decimal upscaling from the addition kernel into an implicit cast. This will simplify the addition kernel to stateless addition (IIUC) and give callers control over how to handle upscaling.

Thanks @bkietz , casting args (rescaling decimal inputs) implicitly before exec looks much better than my current implementation. Will try the approach.

@bkietz , met with one problem, would like to hear your comments. Thanks.

Decimal upscaling is operation dependent. E.g., +,- will upscale arg with smaller scale to align digit, * needn't scaling, / is more complicated.

Implicit args casting happens before kernel is created. DispatchBest only knows arg types, no operation type (kernel dependent) is available. So we cannot figure out the "to be casted" arg type (new precision, scale).
https://github.com/apache/arrow/blob/master/cpp/src/arrow/compute/function.cc#L175

Maybe add another callback kernel->explicit_cast() and call it after or inside DispatchBest? Or create different ScalarFunction struct (and DispatchBest) for each decimal operation?

DispatchBest is aware of the operation; it has access to the function's name. You could write a CommonDecimal() function which returns differing scales/precisions for "add"/"subtract", "divide", and "multiply":

if (auto type = CommonNumeric(*values)) {
  ReplaceTypes(type, values);
} else if (auto type = CommonDecimal(name_, *values)) {
  ReplaceTypes(type, values);
}

Thanks @bkietz , it's almost done except one last catch.

As the output type (precision, scale) is dependent on the inputs, I have a resolver object to calculate output type. The resolver is called with the casted input type, not the original type. It causes problem to division, as the output precision and scale should be calculated from original inputs. No trouble for add/subtract as the output precision/scale is the same for original and casted inputs (digit aligned). Multiply doesn't need cast.

Does it make sense to pass both original input types and the casted types to the resolver [1][2]? We will have to update all existing custom resolver codes.
Maybe add a kernel flag to select passing original or casted input types to the resolver?
Or there are better ways to handle this?

[1] https://github.com/apache/arrow/blob/master/cpp/src/arrow/compute/function.cc#L196
[2] https://github.com/apache/arrow/blob/master/cpp/src/arrow/compute/exec.cc#L495

EDIT: Pushed latest code to ease reviewing. Unit test fails due to this issue.

Rebased