sbroeder opened a new pull request, #5187: URL: https://github.com/apache/calcite/pull/5187
… when getFunctionKind() remaps its kind and 2+ candidates share a name filterOperatorRoutinesByKind's "fourth pass" only runs once at least two candidates survive the earlier passes (a single surviving candidate short-circuits before this pass). It compares candidate.getKind().getFunctionKind() against the call's own, already-bound SqlKind - but that comparison applies getFunctionKind()'s remapping (introduced for this method) to the candidate side only, not to the requested side. For any SqlKind that getFunctionKind() maps to something else - POSITION and the newly-dedicated CHAR_LENGTH both map to OTHER_FUNCTION, along with ~90 others in that switch - this asymmetry means an operator can fail to match even itself, once a second candidate for the same name is present (e.g. because two chained operator tables both contribute an entry for it). The call is rejected outright with "No match found for function signature ...", even though exactly the intended operator was available. ## Jira Link [CALCITE-7724](https://issues.apache.org/jira/browse/CALCITE-7724) ## Changes Proposed <!-- Fix: map both sides of the comparison through getFunctionKind() before comparing, matching normal-case comparisons for kinds it doesn't remap. Added a regression test (chaining the standard operator table with itself to force the two-candidate precondition, the minimal way to reach the buggy pass) and verified the entire SqlValidatorTest suite (589 tests) still passes with the fix. --> -- 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]
