[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305890#comment-14305890
]
Julian Hyde commented on CALCITE-584:
-------------------------------------
Many people find ScannableTable easier to implement than TranslatableTable. We
should allow any Table that can be implemented without rules (ScannableTable,
FilterableTable, ProjectableFilterableTable, TranslatableTable); and we should
consider allowing other Table implementations also (they would need to provide
rules to implement them).
At some point in the process of expanding a TableMacro, we would end up calling
either RelOptTableImpl.toRel or code very similar, that tries various ways to
convert a Table into a RelNode.
A use case would be to read a relation from an HTTP table: {code}select * from
table(web('http://en.wikipedia.org/wiki/List_of_lakes_by_area')){code}
implemented by returning a ScannableTable that reads from a URL, looks for an
HTML table, and parses the contents.
> 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)
