>> =(CAST(PREV(UP.$0, 0)):INTEGER NOT NULL, 100) I don't see the value of reordering this kind of expression. In GPDB, var vs constant comparison is reordered for input ref only, without additional function calls, like $1=5, because it is transformed into range constraints for rex simplification. Perhaps Calcite doesn't need this.
>> What do you think re "$n.field = 42" where $n.field is a dot operator I'm >> not fond of adding complicated checks there, however, I think I can move the >> literal to the right if the other side is a non-literal. Sounds good. I am also fine to keep it unchanged. >> "sort by numeric value" for cases like $1=$8, so that semantics would be >> more or less automatic. I think this is good enough for Calcite, and it has same effect with what I said. Because operand with smaller index always come from left relation, if the two come from different relations. - Haisheng ------------------------------------------------------------------ 发件人：Vladimir Sitnikov<sitnikov.vladi...@gmail.com> 日 期：2019年12月30日 04:33:11 收件人：Apache Calcite dev list<dev@calcite.apache.org> 主 题：Re: Re: [DISCUSS] CALCITE-2450 reorder predicates to a canonical form Just in case, my motivation of comparing by string length first is for the cases like below: =(CAST(PREV(UP.$0, 0)):INTEGER NOT NULL, 100) vs =(100, CAST(PREV(UP.$0, 0)):INTEGER NOT NULL) As for me, the second one is easier to understand, do the expression starts with simpler bits, and the complicated parts are put later. In the same way, it is not amusing to see cases like AND(...,...,...,...,,,.., null, ....) Vladimir
