[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307949#comment-14307949
]
Vladimir Sitnikov commented on CALCITE-584:
-------------------------------------------
{quote}My preferred mode would be to instantiate a small Interpreter to invoke
the bindable table, handle any projects & filters that it refuses at run time,
and convert to enumerable convention. This mode of operation will be as
efficient as using QueryableTable for many data sources.{quote}
What is the purpose of implementing "100% relation algebra" in one more
convention and executor?
I can support almost all the features of ScannableTable, FilterableTable, and
ProjectableFilterableTable right in EnumerableTableScan with a few lines of
code.
Once again: it does not require an full-blown interpreter to call a "scan"
method from within EnumerableTableScan.
Well, RexOver is a beast. However, I am sure it would take a long while for at
least a single implementation of Scannable to appear that supports RexOver kind
of filters.
Note how the patch to EnumerableTableScan does not require reimplementation of
the whole stack and how it does not touch those who use optimizer only.
> 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)
