-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fallback on null empty value in ExprBoundaries::try_from_column #8501
Fallback on null empty value in ExprBoundaries::try_from_column #8501
Conversation
67d7872
to
1d942b7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @razeghi71 -- I think this PR is acceptable to get the queries running, though I think implementing ScalarValue::Map
is likely the more robust solution
To merge this PR I think it needs some sort of test (ideally a query in https://github.com/apache/arrow-datafusion/tree/main/datafusion/sqllogictest) that fails without this PR and works with it. This will ensure we don't accidentally break the system again during a future refactor
Thanks again for your help here
@@ -84,6 +84,10 @@ impl TestContext { | |||
info!("Registering table with many types"); | |||
register_table_with_many_types(test_ctx.session_ctx()).await; | |||
} | |||
"explain.slt" => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I couldn't find a SQL syntax to create a table containing a map data type, I created it here in code.
e9c23ab
to
a700c2a
Compare
Thanks @alamb I added a test in |
a700c2a
to
6e80832
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me -- thank you @razeghi71
Upon some more thought I think the test might be easier to find in |
Which issue does this PR close?
Closes #8262
Rationale for this change
Previously in c9330bc we changed the default empty value for lower and upper bound from
ScalarValue::Null
toScalarValue::try_from(field.data_type())
. but the drawback of this was that for the types that this wasn't implemented (as mentioned in the issue forMap
), this cause the queries to fail. To fix this we can either implement this for other data types (for map I did a prototype in #8488), or fall back onNull
which I did in this PR.What changes are included in this PR?
Explained above.
Are these changes tested?
I tested it using the query provided in the issue.
Are there any user-facing changes?
No