Everybody, I suggest we revert Sarg, and merge it back when it is ready (passes tests).
If no objections, I would proceed with reverting Sarg in 72 hours. I believe we should announce that Calcite 1.26 has severe issues with SEARCH, and people should refrain from using the version. They might corrupt their data, which would be very sad. The current design and implementation for SEARCH has a major issue with nullness For instance, nullableInt=4 is known to return unknown for null input. However, search(x, [..]) is ill-defined, especially when multiple search expressions are combined. simplify(unknownAsTrue, nullableInt=4), simplify(unknownAsUnknown, nullableInt=4), simplify(unknownAsFalse, nullableInt=4) are not easily represented in the current SEARCH format, so it causes wrong results. --- Even though I like Sarg idea, it looks like the current implementation is not really ready, and causes "wrong results from optimization". I did try approaching the issues, and I believe, the best we should do is to revert the thing completely, and reiterate adding it. Frankly speaking, I think we should incorporate "unknownAsTrue / unknownAsUnknown" into search/sarg (instead of the current "containsNull"), however, it would take time. An alternative option is to keep the code in the repository and hope for someone to fix issues. However, I would vote -1 (veto) for the release if nobody fixes issues. The justification is the feature basically blocks Calcite usage, and it can't be disabled. I do not have bad feelings about "untested code sitting in Git". The issues for me are: 1) I won't be able to upgrade to the newer Calcite 2) The current search/sarg implementation has issues with Java null handling. In other words, @nullable annotations do not easily fit there, and the code is going to change a lot since the are functional issues. It is extremely annoying to shoot the moving target while you know the target does not work. 3) I would have to revert mat-calcite-plugin to the previous Calcite version (and fix source-incompatible changes if any) Vladimir
