[SQL] Implementation for user-defined functions#1129
Conversation
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
|
This solution is not 100% because it doesn't allow people to specify additional Rust libraries they can use in their code. |
| this.udf = new HashMap<>(); | ||
| } | ||
|
|
||
| static class RlikeFunction extends SqlFunction { |
There was a problem hiding this comment.
The static classes here were moved from CalciteCompiler.
There was a problem hiding this comment.
Shouldn't we be attributing them?
|
@ryzhyr please review only the rust api and the documentation |
ryzhyk
left a comment
There was a problem hiding this comment.
This is great stuff.
We will need to discuss with @lalithsuresh how to best integrate this with the API.
I think we shouldn't publish doc changes until then, since there is now way for users to provide those Rust files to Feldera or to invoke the compiler directly.
| : type [NOT NULL] | ||
|
|
||
| createFunctionStatement | ||
| : CREATE FUNCTION name '(' [ columnDecl [, columnDecl ]* ] ')' RETURNS generalType |
There was a problem hiding this comment.
Are arguments immutable, so these are pure functions?
There was a problem hiding this comment.
In SQL everything is immutable
There was a problem hiding this comment.
I see other dialects have additional attributes like the language type etc, but those look like they'd be easy to add over time.
| standard Rust types that the compiler uses to implement SQL datatypes. | ||
| The next section explains what these types are. | ||
|
|
||
| Notice the function implemented has an all-capitals name (which is not |
There was a problem hiding this comment.
Seems repetitive. Didn't you explain this above?
| a standard convention for Rust), dictated by the default SQL | ||
| capitalization rules. | ||
|
|
||
| There is no type casting or type inference performed for the function |
There was a problem hiding this comment.
Is this a limitation of the current implementation or is this standard for SQL?
| The SQL family of `INTERVAL` types translates to one of two Rust | ||
| types: `ShortInterval` (representing intervals from days to seconds), | ||
| and `LongInterval` (representing intervals from years to months). | ||
| (Our dialect of SQL does allow mixing the two kinds of intervals in a |
|
|
||
| In the Rust implementation the function always has to return the type | ||
| `Result<T, Box<dyn std::error::Error>>`, where `T` is the Rust | ||
| equivalent expected return type of the SQL function. The Rust |
| equivalent expected return type of the SQL function. The Rust | ||
| function should return an `Err` only when the function fails at | ||
| runtime; in this case the returned error can use the source position | ||
| information to indicate where the error has originated in the code. |
There was a problem hiding this comment.
What happens to the program when the function returns an error?
|
|
||
| The first argument passed to the Rust function is always `pos: | ||
| &SourcePositionRange`. This argument indicates where in the source | ||
| position is placed the code that generated the call to this |
| } | ||
| } | ||
|
|
||
| pub fn st_distance_geopoint_geopoint(left: GeoPoint, right: GeoPoint) -> F64 { |
There was a problem hiding this comment.
Why do we need to pass these arguments by value?
There was a problem hiding this comment.
Three more functions are generated by a macro, with signatures like
st_distance_geopointN_geopoint(left: Option<GeoPoint>, right: GeoPoint) -> Option<F64>. The signature of the other functions is related to this one. They all also call this function.
| @@ -0,0 +1,9 @@ | |||
| //! Crate which just re-exports all the types that are used to implement | |||
There was a problem hiding this comment.
This is a module, not a crate. But more importantly I'm not sure it's useful. Anything that needs to be exported should be exported from lib.rs using pub use ....
There was a problem hiding this comment.
What I want is people who use this stuff to only write one use line.
If there's a simple way to do this, great.
There was a problem hiding this comment.
Right. I don't see how this file helps with this.
There are multiple layers of documentation, and I do need to document the grammar and the compiler flags. I think this is fine. if we postpone documentation we forget about it. |
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
|
We should move this discussion to #1134 |
| : type [NOT NULL] | ||
|
|
||
| createFunctionStatement | ||
| : CREATE FUNCTION name '(' [ columnDecl [, columnDecl ]* ] ')' RETURNS generalType |
There was a problem hiding this comment.
I see other dialects have additional attributes like the language type etc, but those look like they'd be easy to add over time.
| this.udf = new HashMap<>(); | ||
| } | ||
|
|
||
| static class RlikeFunction extends SqlFunction { |
There was a problem hiding this comment.
Shouldn't we be attributing them?
Is this a user-visible change (yes/no): yes