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

[AjimelecGonzalez]

Hello @waterWang, thank you for the contribution!

A few observations after testing this change:

1. The bug still reproduces. I applied your patch and ran mvindex(entity, 1) with the exact setup from [BUG] PPL query with mvindex() fails when plugins.calcite.pushdown.enabled=true #5660. The same CompileException still occurs because the serialized script still shows BIGINT operands in the PLUS call.
2. Root cause is in the serialization layer, not the plan layer. As @RyanL1997 noted, the CAST to INTEGER you add at plan time gets overridden during script pushdown. RexStandardizer.visitCall() widens all exact-numeric operands of arithmetic expressions to BIGINT (for doc-value compatibility), which effectively erases the cast before code generation happens.
3. Existing tests break — CalcitePPLArrayFunctionTest.testMvindexSingleElementNegative and testMvindexRangeNegative are failing with this change.

Suggestion: The fix needs to happen in the serialization layer (RexStandardizer.java) rather than MVIndexFunctionImp.java. Specifically, in visitCall(), after operands are widened, the result type should be cast back to the call's original declared type when it's narrower than what widening produced. This keeps the widening intact for doc-value compatibility while preserving the type contract for consumers like ITEM.