-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Implementing math power function for SQL #2324
Conversation
Implement math POWER function with signatures like https://www.postgresql.org/docs/14/functions-math.html Example usage
Output
|
datafusion/expr/src/function.rs
Outdated
@@ -217,6 +217,11 @@ pub fn return_type( | |||
} | |||
}), | |||
|
|||
BuiltinScalarFunction::Power => match &input_expr_types[0] { | |||
DataType::Int32 | DataType::Int64 => Ok(DataType::Int64), |
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.
what about Int8,Int16, UInt....
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.
Now its changed to be like in https://www.postgresql.org/docs/14/functions-math.html
So the signature is either i64 or f64.
If user column is another col type with less size like i32, f32, i16, etc it will work, however the return type is i64 or f64.
Let me know if this is ok
Hi @Ted-Jiang @xudong963, can you please review again, I'm looking forward to commence to other datafusion tasks |
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 for the contribution @comphead -- looking good 👍
vec![ | ||
TypeSignature::Exact(vec![DataType::Int64, DataType::Int64]), | ||
TypeSignature::Exact(vec![DataType::Float64, DataType::Float64]), | ||
], |
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.
It appears that postgres supports dp
(aka double precision, aka Float64
) and Numeric
https://www.postgresql.org/docs/12/functions-math.html
I think for the initial implementation it would be fine to support Int64
as well, but longer term we should add coercion rules to convert arguments to Float64
before they are actually passed to power
arg1.iter() | ||
.zip(arg2.iter()) | ||
.map(|(a1, a2)| match (a1, a2) { | ||
(Some(a1), Some(a2)) => Some($FUNC(a1, a2.try_into().unwrap())), |
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.
I wonder if .unwrap()
is needed here -- it will cause a panic if the argument can't be converted to whatever $FUNC wants
Does it work if you do
(Some(a1), Some(a2)) => Some($FUNC(a1, a2.try_into().unwrap())), | |
(Some(a1), Some(a2)) => Some($FUNC(a1, a2.try_into()?)), |
Instead?
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.
I came up with (Some(a1), Some(a2)) => Some($FUNC(a1, a2.try_into().ok()?)),
let ctx = SessionContext::new(); | ||
ctx.register_table("test", Arc::new(table))?; | ||
let sql = r"SELECT power(i32, 3) as power_i32, | ||
power(i64, 3) as power_i64, |
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.
A test that takes two columns in addition to a column and a scalar would also be good -- like power(i64, i64)
perhaps
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.
Done
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.
Other than the erroneously included test, I think this is looking good. Thank you @comphead . Nice first contribution
@@ -445,3 +445,169 @@ async fn case_builtin_math_expression() { | |||
assert_batches_sorted_eq!(expected, &results); | |||
} | |||
} | |||
|
|||
#[tokio::test] | |||
async fn case_sensitive_identifiers_aggregates() { |
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.
I still think this test is accidentally included in this PR. It currently exists in aggregates.rs:
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.
Fixed, probably a merge issue. Tried to be in sync with fast changing files
Thanks again all! |
Which issue does this PR close?
Closes #1493
Rationale for this change
Implementing power function for SQL
What changes are included in this PR?
Implementing power function for SQL
Are there any user-facing changes?
User can use math POWER function in SQL statements