xiedeyantu commented on PR #4207: URL: https://github.com/apache/calcite/pull/4207#issuecomment-2679885409
> Yes... Calcite usually is quite smart to simplify these type of things transparently on the fly, so you'd probably need to "force" a bit the situation... What about a RelBuilder scenario with a Scan + Project (trim fields) + Filter + Project (rename); and then applying FilterProjectTranspose and then ProjectRemoveRule? I mean something like: > > ``` > Project(x as a, y as b) > Filter(x>0) > Project(x, y) > Scan (TableA, fields x, y, x) > > => FilterProjectTranspose > > Project(x as a, y as b) > Project(x, y) > Filter(x>0) > Scan (TableA, fields x, y, x) > > => ProjectRemoveRule! (scenario reproduced?) > ``` Many people in the issue gave me suggestions, and I tried them all. If the digest calculation of the project alias is not considered in the calculation of the equivalence relationship, I cannot find a case that can prove that the logic enters the if, because even though it enters the if, stripped also modifies the alias correctly, but stripped cannot be correctly selected in findBestExpr, so does this pr do not need to add a case? I have no better idea. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
