alamb commented on code in PR #9333:
URL: https://github.com/apache/arrow-datafusion/pull/9333#discussion_r1509957464
##########
datafusion/core/src/execution/context/mod.rs:
##########
@@ -1261,7 +1313,38 @@ impl QueryPlanner for DefaultQueryPlanner {
.await
}
}
+/// A pluggable interface to handle `CREATE FUNCTION` statements
+/// and interact with [SessionState] to registers new udf, udaf or udwf.
+
+#[async_trait]
+pub trait FunctionFactory: Sync + Send {
Review Comment:
I think the name is good and describes what this trait does -- namely it
creates functions. I can't think of anything better or more appropriate
##########
datafusion/core/src/execution/context/mod.rs:
##########
@@ -1306,6 +1381,12 @@ pub struct SessionState {
table_factories: HashMap<String, Arc<dyn TableProviderFactory>>,
/// Runtime environment
runtime_env: Arc<RuntimeEnv>,
+ /// [FunctionFactory] to support pluggable user defined function handler.
+ /// It is invoked on `CREATE FUNCTION` and `DROP FUNCTION` statements.
+ ///
+ /// Datafusion generic SQL dialect does not support `CRETE FUNCTION`
statement
Review Comment:
BTW once I release the next version of sqlparser-rs (hopefully today) this
will no longer be true
##########
datafusion/expr/src/logical_plan/ddl.rs:
##########
@@ -303,3 +321,66 @@ pub struct DropCatalogSchema {
/// Dummy schema
pub schema: DFSchemaRef,
}
+
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub struct CreateFunction {
+ // TODO: There is open question should we expose sqlparser types or
redefine them here?
+ // At the moment it make more sense to expose sqlparser types and
leave
+ // user to convert them as needed
+ pub or_replace: bool,
+ pub temporary: bool,
+ pub name: String,
+ pub args: Option<Vec<OperateFunctionArg>>,
+ pub return_type: Option<DataType>,
+ // TODO: move this to new struct here
+ pub params: CreateFunctionBody,
+ //pub body: String,
+ /// Dummy schema
+ pub schema: DFSchemaRef,
Review Comment:
yes, I meant I think we can remove the schema here
##########
datafusion/expr/src/logical_plan/ddl.rs:
##########
@@ -303,3 +321,66 @@ pub struct DropCatalogSchema {
/// Dummy schema
pub schema: DFSchemaRef,
}
+
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub struct CreateFunction {
+ // TODO: There is open question should we expose sqlparser types or
redefine them here?
+ // At the moment it make more sense to expose sqlparser types and
leave
+ // user to convert them as needed
+ pub or_replace: bool,
+ pub temporary: bool,
+ pub name: String,
+ pub args: Option<Vec<OperateFunctionArg>>,
+ pub return_type: Option<DataType>,
+ // TODO: move this to new struct here
+ pub params: CreateFunctionBody,
+ //pub body: String,
+ /// Dummy schema
+ pub schema: DFSchemaRef,
+}
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub struct OperateFunctionArg {
+ // it is not really supported so no need to have it here
+ // currently
+ // pub mode: Option<ArgMode>,
+ pub name: Option<Ident>,
+ pub data_type: DataType,
+ pub default_expr: Option<Expr>,
+}
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub struct CreateFunctionBody {
+ /// LANGUAGE lang_name
+ pub language: Option<Ident>,
+ /// IMMUTABLE | STABLE | VOLATILE
+ pub behavior: Option<Volatility>,
+ /// AS 'definition'
+ pub as_: Option<DefinitionStatement>,
+ /// RETURN expression
+ pub return_: Option<Expr>,
+}
+
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub enum DefinitionStatement {
+ SingleQuotedDef(String),
+ DoubleDollarDef(String),
+}
+
+impl From<sqlparser::ast::FunctionDefinition> for DefinitionStatement {
+ fn from(value: sqlparser::ast::FunctionDefinition) -> Self {
+ match value {
+ sqlparser::ast::FunctionDefinition::SingleQuotedDef(s) => {
+ Self::SingleQuotedDef(s)
+ }
+ sqlparser::ast::FunctionDefinition::DoubleDollarDef(s) => {
+ Self::DoubleDollarDef(s)
+ }
+ }
+ }
+}
+
+#[derive(Clone, PartialEq, Eq, Hash, Debug)]
+pub struct DropFunction {
+ pub name: String,
+ pub if_exists: bool,
+ pub schema: DFSchemaRef,
Review Comment:
Got it -- I tried locally and i see that `DdlStatement::schema()` returns a
reference. Makes sense
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
