[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307941#comment-14307941
]
Jacques Nadeau commented on CALCITE-584:
----------------------------------------
I had some concern about this as well. However, we constrain this to only a
few operators as needed (but all of the algebra), it isn't as bad.
I was actually happy if the core doesn't even have an implementation and we
just test plans. The interpreter was a compromise because Julian rightly
pointed out that we have very poor test coverage if you pull enumerable into a
separate module.
Enumerable needs to be pulled out because there are two very big consumers of
Calcite (Drill and Hive) that find it is actually invasive for their use cases.
Julian's vision of one optimizer to rule requires that implementation concerns
are fully abstracted from the optimizer core codebase or else we'll have to
start forking.
> Allow TableMacro to return Table other than TranslatableTable
> -------------------------------------------------------------
>
> Key: CALCITE-584
> URL: https://issues.apache.org/jira/browse/CALCITE-584
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> The TableMacro.apply method used to return Table but in
> https://github.com/apache/incubator-calcite/commit/aa1f0983c126c23466deb990c96d6ff2dffd908c
> this changed to TranslatableTable. It seems reasonable to allow TableMacro
> to return other sub-types of Table, for example ScannableTable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
