Github user twalthr commented on the pull request:
https://github.com/apache/flink/pull/1237#issuecomment-162622155
So basically what you want to say is: throw your entire code away.
I'm disappointed that you think about the whole concept now, after I have
rebased and reworked the code multiple times. I published a prototype of it in
mid-September (#1127), where I wanted to know if the concept is fine. I won't
have the resources and motivation to start from scratch.
Yes, you are right. Your solution is the nicer one. However, the question
is how much optimizer logic the Table API should have implemented. Actually I
wanted to discuss the following under FLINK-2099, but we can also discuss it
here. If we base some further developed library such as Calcite on top of the
Table API, optimizer logic will be unnecessary in the near future. In a long
term perspective it might make sense to convert Table API DSL to Calcite nodes,
optimize them, and use the Table API plan nodes only as the physical plan nodes
without further optimization. In this case the only thing missing is
predicate/projection pushdown from the Table API tree into the input formats.
Calcite could do push down for us.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
