tkalkirill commented on code in PR #13544:
URL: https://github.com/apache/ignite/pull/13544#discussion_r3948794448
##########
modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/schema/IgniteSchema.java:
##########
@@ -94,23 +96,13 @@ public void removeTable(String tblName) {
* @param func SQL function.
*/
public void addFunction(String name, Function func) {
- for (Function existingFun : getFunctions(name)) {
- List<FunctionParameter> params = func.getParameters();
- List<FunctionParameter> existingParams =
existingFun.getParameters();
-
- if (params.size() != existingParams.size())
- continue;
-
- for (int i = 0; i < params.size(); ++i) {
- FunctionParameter p = params.get(i);
- FunctionParameter existingP = existingParams.get(i);
+ IgniteTypeFactory typeFactory = Commons.typeFactory();
- if
(!p.getType(Commons.typeFactory()).equalsSansFieldNames(existingP.getType(Commons.typeFactory())))
- break;
+ for (Function existingFun : getFunctions(name)) {
+ if (sameParameters(func.getParameters(),
existingFun.getParameters(), typeFactory)) {
Review Comment:
I tried this change and checked `SqlUtil.lookupRoutine` directly. Both
overloads remain candidates for both `INTEGER` and `INTEGER NOT NULL`, and
reversing the candidate order changes which overload is selected.
The earlier integration test was misleading: both methods had the same Java
name, so compilation of the generated Java code could resolve the overload
again. It did not prove that SQL resolution distinguishes nullability.
I reverted the change and kept the comparison ignoring nullability. Treating
int and Integer as the same SQL signature avoids ambiguous selection and
additional rules users would need to remember. This limitation is documented in
both annotations.
--
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]
