[
https://issues.apache.org/jira/browse/CALCITE-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865194#comment-17865194
]
Julian Hyde commented on CALCITE-6465:
--------------------------------------
I would support this.
Timeline could be as follows. It could start off as optional, later it would be
the default (preferred) code generator, and later it could become the only code
generator. Before step 2, it would need to be spun out of Flink. (Flink depends
on Calcite, and we don't want a cyclic dependency between Calcite and Flink.)
Calcite's current generator ('enumerable') generates Java for both relational
expressions (classes that implement Iterator, i.e. the Volcano execution model)
and scalar expressions. Do you see this generator doing relational expressions
or just scalar expressions?
Would the generator make any assumptions about the data format, e.g. that an
incoming row is a java.util.List and that a TIMESTAMP value is represented as a
Java java.lang.Long.
Would the generator make assumptions about how rows sent or received?
> Rework code generator
> ---------------------
>
> Key: CALCITE-6465
> URL: https://issues.apache.org/jira/browse/CALCITE-6465
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Reporter: James Duong
> Assignee: James Duong
> Priority: Major
>
> Holistically replace the (or provide a separate optional) code generator to
> reduce issues such as CALCITE-3094 .
> One suggestion in the comments for CALCITE-3094 has been to use the [code
> generator from
> Flink.|https://nightlies.apache.org/flink/flink-docs-release-1.3/api/java/org/apache/flink/table/codegen/CodeGenerator.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
