[SQL/PPL] Fix the count(*) and dc(field) to be capped at MAX_INTEGER #4416

[aalva500-prog]

Description

Currently, SQL/PPL Count Query Is Maxed at MAX_INT

For example, in the following query requestId is capped at the value of max(integer), however, the actual number of requestId could be higher:

{
"query": ""source = accounts | stats count(requestId)""
}
{
  "schema": [
    {
      "name": "count(requestId)",
      "type": "integer"
    }
  ],
  "datarows": [
    [
      2147483647
    ]
  ],
  "total": 1,
  "size": 1
}

This PR addresses the above issue by changing the return data type of the count() function from integer to long, so the new result will be as follows:

{
"query": ""source = accounts | stats count(requestId)""
}
{
  "schema": [
    {
      "name": "count(requestId)",
      "type": "bigint"
    }
  ],
  "datarows": [
    [
      2147483647
    ]
  ],
  "total": 1,
  "size": 1
}

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[RyanL1997]

https://github.com/opensearch-project/sql/actions/runs/18144320253/job/51642545887?pr=4418#step:6:575

Got

SQLBackwardsCompatibilityIT > testBackwardsCompatibility FAILED
    java.lang.AssertionError: 
    Expected: iterable with items [(name=COUNT(*) FILTER(WHERE age > 35), alias=null, type=integer)] in any order
         but: not matched: <{"name":"COUNT(*) FILTER(WHERE age > 35)","type":"long"}>
        at __randomizedtesting.SeedInfo.seed([27E773C284B404C7:CCD84E0CFE6FD14D]:0)
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)

        at org.opensearch.sql.util.MatcherUtils.verify(MatcherUtils.java:196)
        at org.opensearch.sql.util.MatcherUtils.verifySchema(MatcherUtils.java:144)
        at org.opensearch.sql.bwc.SQLBackwardsCompatibilityIT.verifySQLQueries(SQLBackwardsCompatibilityIT.java:190)
        at org.opensearch.sql.bwc.SQLBackwardsCompatibilityIT.testBackwardsCompatibility(SQLBackwardsCompatibilityIT.java:126)
  1> [2025-09-30T17:51:35,784][INFO ][o.o.s.b.SQLBackwardsCompatibilityIT] [testBackwardsCompatibility] before test
  1> [2025-09-30T17:51:35,946][INFO ][o.o.s.b.SQLBackwardsCompatibilityIT] [testBackwardsCompatibility] initializing REST clients against [http://[::1]:36159, 

[Swiddis]

lgtm, assuming tests pass

[LantaoJin]

Just a question: are we still need to fix v2 only bugs? Now the default engine migrate to v3 from 3.3.0, and this fixing seems no plan to backport to 3.1.

[RyanL1997]

Just a question: are we still need to fix v2 only bugs? Now the default engine migrate to v3 from 3.3.0, and this fixing seems no plan to backport to 3.1.

Hi @LantaoJin, this is related to a serverless issue I think. Serverless is still on a customized version of 2.17 of sql which is still relying on the legacy engine. cc @aalva500-prog

[aalva500-prog]

Hi @LantaoJin, @RyanL1997 is correct, this issue was reported from serverless side. The latest OS version they use is 2.17 customized. I'm not sure when they plan to migrate to V3, but I don't think it will be in the near future.