fix: cast mvindex index arithmetic to INTEGER type for Calcite ITEM compatibility (#5660)

[waterWang]

Description

Fixes #5660

When mvindex() is used in a PPL query with Calcite pushdown enabled, the index conversion +(index, 1) produces a BIGINT (long) value instead of INTEGER (int). The INTERNAL_ITEM operator expects SqlTypeFamily.INTEGER for the index parameter, causing a CompileException:

No applicable constructor/method found for actual parameters "java.util.List, long, int, boolean";
candidates are: "public static java.lang.Object org.apache.calcite.runtime.SqlFunctions.arrayItemOptional(java.util.List, int, int, boolean)"

Root Cause

The add and subtract methods in MVIndexFunctionImp.java use Calcite's SqlStdOperatorTable.PLUS/MINUS, which widen the result type to BIGINT when both operands are INTEGER. The INTERNAL_ITEM operator's type checker expects SqlTypeFamily.INTEGER, but receives BIGINT (part of SqlTypeFamily.NUMERIC).

Fix

Wrap the PLUS/MINUS results in a CAST(INTEGER) to ensure the index arithmetic always produces INTEGER-typed values for the ITEM/ARRAY_SLICE operators.

Testing

• Existing CalcitePPLArrayFunctionTest covers mvindex with positive and negative indices
• The fix ensures the +(1, 1) expression is cast to INTEGER before being passed to ITEM

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Prevent potential integer overflow The cast to INTEGER may cause overflow or data loss if the addition result exceeds INTEGER range. Consider validating that operands are within safe bounds before casting, or use a larger type like BIGINT if the domain allows values beyond INTEGER limits. core/src/main/java/org/opensearch/sql/expression/function/CollectionUDF/MVIndexFunctionImp.java [68-70] RexNode result = builder.makeCall(SqlStdOperatorTable.PLUS, left, right); return builder.makeCast( - builder.getTypeFactory().createSqlType(SqlTypeName.INTEGER), result); + builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT), result); Suggestion importance[1-10]: 3 __ Why: While the suggestion correctly identifies the location and raises a valid concern about potential overflow, the context indicates this is for "internal, int-domain array-index math" as stated in the method comment. Array indices are typically within INTEGER range, making BIGINT unnecessary and potentially inconsistent with the intended design. The suggestion's improved code also doesn't match its own recommendation of "validating operands" but instead just changes the type.	Low