>Longer term I would like EnumerableTableScan to work only on top of a >QueryableTable Why's that? If there is no expression, you can just EnumerableRelImplementor.stash the "any_table" and that is it. No expression is required. Just-in-time stashing to rescue.
However, I do agree it makes sense to dodge RelOptTableImpl.getExpression: I agree there are cases when expression is known only at parse-time (e.g. as a result of org.apache.calcite.adapter.enumerable.EnumerableRelImplementor#stash) > You can't understand how broken it was unless you run testStream and try to > get it working Our typical strategy was "test is a detailed design", however for streamable it is not yet the case. I do not like how you sneak BINDABLE rules in while "ENABLE_BINDABLE=false". Can you clarify what do you mean by stream tables? How it should work? I cannot understand how it is supposed to work. All the rules just eliminate LogicalDelta. I believe I can kill all the bindable rules and manage testStream to fly, however I do not want to get my hands dirty on the thing that should work in unknown to me fashion. Is the sole purpose of StreamableTable that it returns a table on demand? How it is different from regular table/table macro/table function? > ImmutableIntList#identity create an AbstractList<Integer> ( I do not follow you. ImmutableIntList#identity should create just ImmutableIntList. What's verbose and less efficient with that? > Each "scan" creates an Enumerable, not an Enumerator. Enumerable does not > acquire resources My bad. Enumerable does not provide a way to release resources indeed. >This is emulating the behavior of ReflectiveTable and FieldSelector. I put it >in to make existing tests work. Why emulate if you can reuse? Who guarantees that those implementations would not diverge in the future? Vladimir
