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
