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. Julian On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <[email protected]> wrote: > Il ven 17 nov 2017, 19:19 Julian Hyde <[email protected]> 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 <[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 >> >>> > >> >>> > >> >>> >> >>> >> >> >> >> >> > -- > > > -- Enrico Olivelli
