[
https://issues.apache.org/jira/browse/FLINK-11961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073774#comment-17073774
]
Timo Walther edited comment on FLINK-11961 at 4/2/20, 2:21 PM:
---------------------------------------------------------------
This issue can be solved soon. After FLIP-65, we clearly separated definition
and runtime implementation. All we need to do is to provide a map from
`FunctionDefinition` to runtime class that contains `eval(...)`. Since
functions can work on internal data formats and can be overloaded, all the
complex logic in the code generator can be removed and replaced by the logic in
the bridging call gen. [~jark] I would pick up this issue, after 1.11 if you
don't find time.
was (Author: twalthr):
This issue can be solved soon. After FLIP-65, we clearly separated definition
and runtime implementation. All we need to do is to provide a map from
`FunctionDefinition` to runtime class that contains `eval(...)`. Since
functions can work on internal data formats and can be overloaded, all the
complex logic in the code generator can be removed and replaced by the logic in
the bridging call gen. [~jark] I would pick up this issue, after 1.10 if you
don't find time.
> Clear up and refactor code generation of scalar functions and operators
> -----------------------------------------------------------------------
>
> Key: FLINK-11961
> URL: https://issues.apache.org/jira/browse/FLINK-11961
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / Planner
> Reporter: Jark Wu
> Assignee: Jark Wu
> Priority: Minor
>
> Currently, the code generation of scalar functions and operators are complex
> and messy.
> There are several ways to support codegen for a function/operator:
> (1) Implement {{generate...}} in {{ScalarOperatorGens}} and invoke it in the
> big match pattern of {{ExprCodeGenerator}}.
> (2) Implement a {{CallGenerator}} and add it to {{FunctionGenerator}}.
> (3) Implement a util method and add it to {{BuiltinMethods}} and
> {{FunctionGenerator}}.
> It will confuse developer which is the most efficient way to implement a
> function.
> In this issue, we will propose a unified way to code generate
> functions/operators.
> Some initial idea:
> 1. Introduce an {{ExprCodeGen}} interface, and all the function/operators
> code generator should extend this to implement the {{codegen}} method. It's
> like a combination of {{PlannerExpression}} and {{CallGenerator}}.
> 2. Rename {{ExprCodeGenerator}} to {{RexCodeGenerator}}.
> 3. Use a big match pattern to mapping {{RexCall}} to specific {{ExprCodeGen}}
> {code:scala}
> trait ExprCodeGen {
> def operands: Seq[GeneratedExpression]
> def resultType: InternalType
> def codegen(ctx: CodeGeneratorContext): GeneratedExpression
> }
> case class ConcatCodeGen(operands: Seq[GeneratedExpression]) extends
> ExprCodeGen {
> override def resultType: InternalType = InternalTypes.STRING
> override def codegen(ctx: CodeGeneratorContext): GeneratedExpression = {
> nullSafeCodeGen(ctx) {
> terms => s"$BINARY_STRING.concat(${terms.mkString(", ")})"
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)