> IMHO It would better to keep somethin like an EnumerableProjection which > renames the fields
I disagree. If we commit to preserving field names all kinds of optimization are not possible. In Calcite RelNode world, field names are a hint to make debugging easier but are not ultimately reliable. The reliable way to reference fields is by position. Julian On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <[email protected]> wrote: > I run the debugger on your test case. > IMHO The BindableTableScan RelNode does not keep the original aliases of > the query. > The test cases runs CalciteConnection, maybe there is some magic during the > execution of the query. > Can you provide me some insight ? > Maybe it is better that I provide a reproducer. > I am not using CalciteConnection but only the planner > > Thanks > Enrico > > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <[email protected]>: > >> your test is working >> >> I will try to understand where is the problem in my code >> >> b.q. I am looking for a sponsor for this patch, which is a real blocker >> for me, could you pleas take a look Luis ? >> https://github.com/apache/calcite/pull/568 >> >> Thank you >> Enrico >> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer < >> [email protected]>: >> >>> Please insert the following test in ScannableTableTest and run: >>> /** ProjectableFilterableTable project push down using alias. */ >>> @Test public void testPFPushDownWithAlias() throws Exception { >>> final StringBuilder buf = new StringBuilder(); >>> final Table table = new BeatlesProjectableFilterableTable(buf, true); >>> CalciteAssert.that() >>> .with(newSchema("s", "beatles", table)) >>> .query("select \"i\" as theKey from \"s\".\"beatles\"") >>> .explainContains("EnumerableInterpreter\n" >>> + " BindableTableScan(table=[[s, beatles]], >>> projects=[[0]])\n") >>> .returnsUnordered("THEKEY=4", >>> "THEKEY=4", >>> "THEKEY=6", >>> "THEKEY=5"); } >>> It passes for me. >>> You'll need the updated version of this test class, because it was >>> recently refactored. >>> It's usually easier for other people to test the problem if you create >>> runnable test cases to show the problem. Em sexta-feira, 17 de novembro >>> de 2017 14:29:09 BRST, Enrico Olivelli <[email protected]> escreveu: >>> >>> In the RowType I have 'k1' and not "thekey" >>> >>> Enrico >>> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer >>> <[email protected] >>> >: >>> >>> > Did you execute the query? >>> > ProjectRemoveRule removes the Project when it is "trivial". Since the >>> > only used project was pushed to BindableTableScan, the Project would >>> only >>> > set the alias, but that can be done in row type. >>> > The result is correct because RowType is preserved with the alias. It >>> > just does not show in the plan. >>> > However, I seems that repeating a column with different aliases >>> generates >>> > an error: >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1 ='mykey2' >>> > >>> > Regards, >>> > Luis Fernando >>> > >>> > Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico >>> Olivelli < >>> > [email protected]> escreveu: >>> > >>> > Hi, >>> > I have a ProjectableFilterableTable, it seems to me that the >>> BindablaScan >>> > RelNode does not keep track of column name aliases in the original >>> > projection >>> > >>> > Example: >>> > >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2' >>> > >>> > -- Logical Plan >>> > LogicalProject(THEKEY=[$0]) >>> > LogicalFilter(condition=[=($0, 'mykey2')]) >>> > EnumerableTableScan(table=[[tblspace1, tsql]]) >>> > >>> > -- Best Plan >>> > EnumerableInterpreter >>> > BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0, >>> > 'mykey2')]], >>> > projects=[[0]]) >>> > >>> > Is this correct ? >>> > IMHO It would better to keep somethin like an EnumerableProjection which >>> > renames the fields >>> > >>> > Am I missing something ? >>> > Thanks >>> > Enrico >>> > >>> > >>> >>> >> >>
