You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2019/02/18 14:18:01 UTC

[GitHub] twalthr commented on issue #7664: [FLINK-11449][table] Uncouple the Expression class from RexNodes.

twalthr commented on issue #7664: [FLINK-11449][table] Uncouple the Expression class from RexNodes.
URL: https://github.com/apache/flink/pull/7664#issuecomment-464747146
 
 
   @KurtYoung What you mentioned to "use FunctionDefinition to represent details information, quite similar with Calcite's RexNode/SqlOperator" is exactly what I have in mind as well as a long-term vision.
   
   The function definition would take information of accepted parameter types or parameter type families, input and return type inference etc. However, this is future work. It would unify built-in and user-defined functions in the future and should be implemented together with the type system rework. I started with a design document for this but will postpone it for now. In the future, we won't need dedicated classes for every expression. Only a function definition and a visitor that translates common functions into RexNodes such that the optimizer can recognize them.
   
   But for now, let's simply translate "generic expressions" such as `Call`s to actual expression classes in a big visitor pattern in order to speed up the Blink merge.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services