Stamatis>@Vladimir: Can you specify which JIRA issue(s) you would like to see solved Stamatis>for the next release?
RexProgramFuzzyTest should be enabled, and Sarg-related fuzzing should be implemented as well. RexFuzzer should generate Sarg expressions. RexInterpreter should be able to evaluate search/sarg. RexProgramFuzzyTest should pass both with and without expandSearch. I'm afraid I have no time on executing RexProgramFuzzyTest and logging failures as JIRA cases. I assume committers should ensure the code they commit passes existing tests, and they should ensure new code is accompanied by tests as well. It looks like I tried everything: a) I kindly asked Julian to refrain from committing untested code (both in PR and in the very first message of the thread) b) I highlighted major design issues (see unknownAs in [1]) c) I provided sample failures (see "sample input" in [2]) d) I even suggested the plan to resolve the issues: "revert search/sarg", "re-enable fuzzer", "fix issues discovered by the fuzzer", "re-add search/sarg". Not only I suggested the approach, I implemented a noticeable part of it (e.g.I re-enabled the fuzzer and added relevant code fixes to make the test pass, see CALCITE-4398, CALCITE-4397, CALCITE-4388), however, Julian discarded all of it with "A commit war is no way to proceed" comment. Now I stop doing everything related to search/sarg. Of course, if there's a release, and the fuzzer is still disabled, I would put my -1 vote. [1] https://lists.apache.org/thread.html/r602b7e17cf076f00dfbd946e814cea098a7b81e0b252bfa6e2fd5e9b%40%3Cdev.calcite.apache.org%3E [2] https://lists.apache.org/thread.html/r6d509f7202195362b33f93c076b5010bd1a9a5ac1e4fa6814819077c%40%3Cdev.calcite.apache.org%3E Vladimir
