Benchao is correct that we cannot guarantee column names. So, this is a feature request rather than a bug. I still think you should log it.
RelFieldTrimmer works top-down, deducing a bit-set of the columns that each relational operator needs from its input(s). To solve this problem, it would need to pass the desired names of those columns. That might make the trimmer a little bit less efficient, and somewhat more complex. The trimmer ought to be allowed to ignore the recommended column names; I don’t think we would want to introduce a Project for the sole purpose of renaming columns. Julian > On Oct 23, 2023, at 4:31 AM, Benchao Li <[email protected]> wrote: > > AFAIK, usually we cannot guarantee the columns names in the > optimization phase. However, I think we can still try our best to > preserve it while not introducing too much complexity. > > For this case, I'd like to take it as an improvement we can do. > > Zhe Hu <[email protected]> 于2023年10月23日周一 18:32写道： >> >> Hi, community. I encounter a problem when I try RelFieldTrimmer. >> I run the following SQL in SqlToRelConverterTest: >> select ename as did from emp where ename='a' limit 10 >> >> >> I get planA without RelFieldTrimmer: >> LogicalSort(fetch=[10]) >> LogicalProject(DID=[$1]) >> LogicalFilter(condition=[=($1, 'a')]) >> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) >> >> >> I get planB with the RelFieldTrimmer: >> LogicalSort(fetch=[10]) >> LogicalFilter(condition=[=($0, 'a')]) >> LogicalProject(ENAME=[$1]) >> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) >> >> >> However, the column alia DID for ENAME is missing in planB. And I think the >> project should be LogicalProject(DID=[$1]) in planB. >> Do I miss some relevant rules in Calcite or is it a issue we need to fix? >> >> >> Best, >> ZheHu > > > > -- > > Best, > Benchao Li
