Skip to content

GH-41336: [C++][Compute] Fix the bug of decimal types skipping cast in IfElse related expression function calls#41363

Closed
ZhangHuiGui wants to merge 2 commits intoapache:mainfrom
ZhangHuiGui:fix-41336
Closed

GH-41336: [C++][Compute] Fix the bug of decimal types skipping cast in IfElse related expression function calls#41363
ZhangHuiGui wants to merge 2 commits intoapache:mainfrom
ZhangHuiGui:fix-41336

Conversation

@ZhangHuiGui
Copy link
Copy Markdown
Contributor

@ZhangHuiGui ZhangHuiGui commented Apr 24, 2024

Rationale for this change

Fix the bug of decimal types skipping cast in IfElse related expression function calls

What changes are included in this PR?

  1. Added the output resolver for the IfElse related kernel functions : if_else, case_when, coalesce.
    Output resolver will make sure the input decimal types casted correctly by their DispatchBest in expression call.
  2. Added the tests include the combination of the decimal types and other numeric types to make sure they can be
    cast and execute correctly as CallFunction.

Are these changes tested?

Yes

Are there any user-facing changes?

No

Co-authored-by ZhangHuiGui 2689496754@qq.com
Co-authored-by laotan332 qinpengxiang@outlook.com

@github-actions
Copy link
Copy Markdown

⚠️ GitHub issue #41336 has been automatically assigned in GitHub to PR creator.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

< 0?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The returned invalid status used in the logic :
https://github.com/bkietz/arrow/blob/c25866bc59e30e43e8dc3b05f3973d48074c3594/cpp/src/arrow/compute/expression.cc#L551-L552

Let the expression call go into DispatchBest so they can be cast correctly.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In BindNonRecursive:
FinishBind will do output type resolve. For the first time go into the resolver, our decimal related types haven't cast, we could check if the decimal types have different precision and scale.

And then return invalid to make the BindNonRecursive go into IfElse's related function's DispatchBest and do cast.

After that, when we go into type resolver in BindNoRecursive second time, we could find the decimal types already cast to same precision and scale, so we could find the correct result output type.

@github-actions github-actions bot added awaiting committer review Awaiting committer review and removed awaiting review Awaiting review labels Apr 24, 2024
};

template <typename ResolverForOtherTypes>
Result<TypeHolder> ResolveDecimalCaseType(KernelContext* ctx,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name suggestion: ResolveDecimalCaseWhenOutputType

Because "DecimalCase" is ambiguous by "case" being a word that would fit here, but it actually refers to the kernel function called "CaseWhen".

Comment on lines +1208 to +1209
if (is_floating(type.id()) || is_integer(type.id())) {
return Status::Invalid("Need to cast numeric types containing decimal types");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a better approach for these failures is to have kernels that fail. You write input matchers to cover all cases and dispatch to the fail kernels for types that can't be handled without casts.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the approach with TypeMatcher is more suitable. If there is no problem with the PR #41012 that contains a new matcher interface for combination-types, current PR will continue to be promoted.

@github-actions github-actions bot added awaiting changes Awaiting changes and removed awaiting committer review Awaiting committer review labels May 14, 2024
@zanmato1984
Copy link
Copy Markdown
Contributor

Issue fixed by #47479. Closing this one. Thanks you all the same @ZhangHuiGui !

@zanmato1984 zanmato1984 closed this Sep 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants