I solved my problem just by capturing the original rowtype after sql parser. Thanks Enrico
Il ven 17 nov 2017, 22:44 Enrico Olivelli <eolive...@gmail.com> ha scritto: > > > Il ven 17 nov 2017, 22:36 Julian Hyde <jh...@apache.org> ha scritto: > >> Translating to RelNode loses some metadata. When preparing a SQL >> statement, we use the column names and types given to us by the >> validator for use by ResultSetMetaData. >> >> There's a related interesting case where a column appears in ORDER BY >> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The >> RelNode needs to have 2 columns but the ResultSet thinks it only has >> one. >> > > I am observing that Calcite tends to add support fields always at the > 'right'. Is this a general behaviour or I am lucky and all the plans I am > seeing behave this way ? > > I think I will try to capture field names from the SqlNodes, but this will > be feasible if and only if the first N selected RelNodes of the physical > plan represent the first N SqlNodes in the Select clause > > Enrico > > >> Julian >> >> >> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <eolive...@gmail.com> >> wrote: >> > Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto: >> > >> >> > 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. >> >> >> > >> > >> > I understand your point Julian. In my case I want the final resultset to >> > have knowledge of the alias requested by the user. >> > >> > Select a as b from table >> > >> > ResultSet rs = ... >> > String col = rs.getString("b"); >> > If I am losing the alias I can't support this case. >> > The test case from Luis is working so there is some trick I am missing >> > >> > Enrico >> > >> > >> >> Julian >> >> >> >> >> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eolive...@gmail.com> >> >> 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 <eolive...@gmail.com>: >> >> > >> >> >> 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 < >> >> >> lfka...@yahoo.com.br.invalid>: >> >> >> >> >> >>> 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 <eolive...@gmail.com> >> escreveu: >> >> >>> >> >> >>> In the RowType I have 'k1' and not "thekey" >> >> >>> >> >> >>> Enrico >> >> >>> >> >> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer >> >> >>> <lfka...@yahoo.com.br.invalid >> >> >>> >: >> >> >>> >> >> >>> > 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 < >> >> >>> > eolive...@gmail.com> 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 >> >> >>> > >> >> >>> > >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> > -- >> > >> > >> > -- Enrico Olivelli >> > -- > > > -- Enrico Olivelli > -- -- Enrico Olivelli