Function signatures in Substrait extensions can use type variables for polymorphism. Examples from the core extensions:
any1, any2 - match any type (e.g., first_value(any1) -> any1)any1? - nullable type variabledecimal<P1,S1> - decimal with parameter variables for precision/scalevarchar<L1> - varchar with length parameter variable
Currently, when parsing a return type or argument type that contains these variables, ConcreteType::try_from(TypeExpr) fails with errors like InvalidAnyTypeVariable, and the function is skipped with a NotYetImplemented error.
https://github.com/substrait-io/substrait-rs/blob/main/src/parse/text/simple_extensions/scalar_functions.rs#L148-L156
Supporting this would require either an owned version of TypeExpr (which currently borrows from the source string) or a new type that can represent both concrete types and type expressions with variables. Properly using these for type checking and function resolution would be additional work beyond just parsing.
Function signatures in Substrait extensions can use type variables for polymorphism. Examples from the core extensions:
any1,any2- match any type (e.g.,first_value(any1) -> any1)any1?- nullable type variabledecimal<P1,S1>- decimal with parameter variables for precision/scalevarchar<L1>- varchar with length parameter variableCurrently, when parsing a return type or argument type that contains these variables,
ConcreteType::try_from(TypeExpr)fails with errors likeInvalidAnyTypeVariable, and the function is skipped with aNotYetImplementederror.https://github.com/substrait-io/substrait-rs/blob/main/src/parse/text/simple_extensions/scalar_functions.rs#L148-L156
Supporting this would require either an owned version of
TypeExpr(which currently borrows from the source string) or a new type that can represent both concrete types and type expressions with variables. Properly using these for type checking and function resolution would be additional work beyond just parsing.