[
https://issues.apache.org/jira/browse/CALCITE-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047185#comment-17047185
]
Danny Chen commented on CALCITE-3769:
-------------------------------------
[~zabetak]
bq. I also find it a bit weird that EnumerableTableScanRule now can produce a
BindableTableScan
I already said the reason in the EnumerableTableScanRule comments, this is just
how Calcite implements that. BindableTableScan and EnumerableTableScan have
different features. And we choose the one that can make a filter expressions
push down.
This is just our current implementation, Calcite has 2 impls, one is Bindable,
one is Enumerable, we choose the one we want for different kind of tables. If
this is not what the user want, just change to a different rule impl, just like
what [~anha] did, and he also gives a +1 finally in the voting.
Just like what [~eolivelli] has fixed, return "null" instead of throwing "not
implemented", this is the right direction, the original code returns a
EnumerableTableScan without any expression which would never be implemented.
The changes let usee be aware of the right direction to go.
[~vladimirsitnikov] don't accuse me for plan compatibility, i modified
thousands of plans just because of CALCITE-3713 in Flink. And CALCITE-2450 was
merged even Julian and i gave a -1.
> Is there an absolute need to include this refactoring in 1.22.0?
I need this for Flink in 1.22.0, i have said it above.
If we need more discussion, take it now.
> Deprecate TableScanRule
> -----------------------
>
> Key: CALCITE-3769
> URL: https://issues.apache.org/jira/browse/CALCITE-3769
> Project: Calcite
> Issue Type: Wish
> Components: core
> Affects Versions: 1.21.0
> Reporter: Danny Chen
> Assignee: Danny Chen
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The TableScanRule is the only planner rule that for a logical node(e.g. the
> table scan), its function is to pass along the cluster object and invoke the
> RelOptTable#toRel which is very trivial because it supplies only a simple
> ToRelContext that does not support expanding view/passing table hints.
> For rels that come from the sql-to-rel conversion, there is already a table
> conversion logic[1]. This code gives a more powerful ToRelContext that has
> the complete functionality.
> The only reason that I saw the meaning of existing TableScanRule is for the
> TableScan that comes from the RelBuilder#scan.
> So I would suggest to deprecate the TableScanRule, instead, we support
> translating the table directly in RelBuilder#scan,
> -We also add a new interface RelBuilder#scan(Iterable<String> tableNames,
> ToRelContext context), so that user can pass in a more powerful ToRelContext
> explicitly.- User can customize a TableScanFactory in the RelBuilder to do
> this.
> [1]
> https://github.com/apache/calcite/blob/d6fa25cd11625ad7b4b74dafbd0211c701b38d49/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L3498
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
