[SPARK-17981] [SPARK-17957] [SQL] [BACKPORT-2.0] Fix Incorrect Nullability Setting to False in FilterExec #15781
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
This PR is to backport the fix #15523 to 2.0.
When
FilterExeccontainsisNotNull, which could be inferred and pushed down or users specified, we convert the nullability of the involved columns if the top-layer expression is null-intolerant. However, this is not correct, if the top-layer expression is not a leaf expression, it could still tolerate the null when it has null-tolerant child expressions.For example,
cast(coalesce(a#5, a#15) as double). Althoughcastis a null-intolerant expression, but obviouslycoalesceis null-tolerant. Thus, it could eat null.When the nullability is wrong, we could generate incorrect results in different cases. For example,
The optimized plan is like
Without the fix, it returns an empty result. With the fix, it can return a correct answer:
How was this patch tested?
Added test cases to verify the nullability changes in FilterExec. Also added a test case for verifying the reported incorrect result.