Hi Stamatis, Regarding aliases, there is no guarantee that they will be retained. > There are various places where there is some effort to keep them intact but > your code shouldn't rely on this. >
Yeah, I took a closer look at the source code and what you are saying seems to make sense. I have resorted to extracting the aliases before optimizing the plan. Why do you need to do logical -> physical -> logical transformation? > Primarily so that the optimized plan can be visited. By visiting the plan, I can obtain data about particular operators which is later used to construct operators for another (dataflow)system (in C++). I am not sure if it is the right way to do it, but it got things up and running. Thanks for your response! Best regards, Ishan On Thu, Jun 24, 2021 at 3:44 AM Stamatis Zampetakis <[email protected]> wrote: > Hi Ishan, > > Why do you need to do logical -> physical -> logical transformation? > > Regarding aliases, there is no guarantee that they will be retained. > There are various places where there is some effort to keep them intact but > your code shouldn't rely on this. > > Best, > Stamatis > > On Tue, Jun 15, 2021 at 4:37 AM Sharma, Ishan <[email protected]> > wrote: > > > Hi folks, > > There exists an API to get the column name for the aggregate column ( > > *getNamedAggCalls*), I can't seem to find a similar API for group > columns, > > is there a way to obtain the same in *LogicalAggregate*? > > > > Currently, I am optimizing the logical plan into a physical plan (in > > bindable convention) and then converting it back to a plan with logical > > nodes via *ToLogicalConverter. *As a consequence of > > *AGGREGATE_PROJECT_MERGE* rule, the project gets removed and hence > > information about the column aliases for the group columns in aggregate > > does not seem to be available. I guess I am missing something minor. > > > > Thanks, > > Ishan > > >
