[fix](fe) Reject LARGEINT bucket of NTILE - #68030
Merged
Merged
Conversation
Problem Summary:
Frontend declared `NTILE(LARGEINT) -> LARGEINT`, but `WindowFunctionNTile` in backend always
returns BIGINT, since the bucket index is computed with an int64 value. As a result, a
legal-looking window query
select ntile(170141183460469231731687303715884105727) over (order by k) from t;
failed in the prepare phase with an internal error instead of a clear user error:
[INTERNAL_ERROR]Result type of ntile is not matched, planner expect LARGEINT, but get BIGINT
Fix:
1. remove the LARGEINT signature of NTILE, so that every declared signature returns BIGINT and
keeps consistent with backend;
2. reject a LARGEINT bucket in `checkLegalityBeforeTypeCoercion` with an explicit
AnalysisException, because backend computes the bucket index with an int64 value and can
not handle a LARGEINT bucket;
3. drop the redundant `buckets` field, which duplicated the first child and was not initialized
when the expression is rebuilt by `withChildren`, and read the first argument through
`getArgument(0)`.
After the fix, the query above is rejected during analysis with
`The bucket of NTILE must be an integer within the range of BIGINT, but got LARGEINT`, while an
integer bucket (TINYINT/SMALLINT/INT/BIGINT) keeps working as before.
None
- Test: Regression test / Unit Test
- `./run-regression-test.sh --run -f regression-test/suites/query_p0/sql_functions/window_functions/test_ntile_function.groovy`
- `./run-fe-ut.sh --run org.apache.doris.nereids.trees.expressions.functions.window.NtileBucketTest`
- Behavior changed: Yes. A LARGEINT bucket of NTILE is rejected during analysis with an explicit
error message, instead of failing in the prepare phase with an internal type mismatch error.
- Does this need documentation: No
jacktengg
requested review from
924060929,
englefly,
morrySnow and
starocean999
as code owners
September 15, 2026 15:55
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Automated review result: no blocking issues found at head cbfe7060eab84c0868c9476a0c661a70e91f46b4. This change looks good to merge based on static review.
Critical checkpoint conclusions:
- Goal and proof: the patch rejects LARGEINT buckets during Nereids analysis before explicitly-castable signature resolution, removes the invalid LARGEINT return signature, and leaves every accepted signature returning BIGINT. The generic window translator therefore sends a BIGINT result/intermediate type, matching BE
WindowFunctionNTile's fixed INT64 result. The two new regression cases cover both a parser-inferred LARGEINT and an in-range value explicitly typed LARGEINT; existing ordered positive cases continue to cover NTILE execution. - Scope and lifecycle: the two-file change is small and focused. Removing the duplicate
bucketsfield and readinggetArgument(0)aligns legality checks with the canonical child used by reconstruction, equality/hash, signature search, and translation. No stale-child or signature-cache path was found. - Concurrency, configuration, compatibility, and parallel paths: no concurrency/locking, configuration, persistence, transaction, data-write, observability, or memory-management behavior changes. There is one FE NTILE registry/translation chain and one BE registration. New-FE plans remain compatible with old and new BEs; no protocol or storage-format change is involved.
- Runtime correctness and performance: positive BIGINT buckets, including the maximum value, cannot cause a bucket-driven divide by zero or overflow in the reachable BE arithmetic. The new FE checks are constant-time analysis work and introduce no hot-path regression.
- Tests and results: the added cases use the required
test { sql; exception }form and require no.outrows; existing positive output is deterministically ordered. Per the automated-review runner contract, I did not run builds or tests, so this conclusion is static and does not independently verify the author's reported test execution. - User focus: no additional review focus was provided; the full PR was reviewed.
Contributor
Author
|
run buildall |
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
TPC-H: Total hot run time: 17315 ms |
Contributor
TPC-DS: Total hot run time: 82866 ms |
Contributor
ClickBench: Total hot run time: 14.85 s |
Contributor
FE Regression Coverage ReportIncrement line coverage |
starocean999
approved these changes
Sep 16, 2026
Contributor
|
PR approved by anyone and no changes requested. |
github-actions
Bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem Summary:
Frontend declared
NTILE(LARGEINT) -> LARGEINT, butWindowFunctionNTilein backend always returns BIGINT, since the bucket index is computed with an int64 value. As a result, a legal-looking window queryfailed in the prepare phase with an internal error instead of a clear user error:
Fix:
checkLegalityBeforeTypeCoercionwith an explicit AnalysisException, because backend computes the bucket index with an int64 value and can not handle a LARGEINT bucket;bucketsfield, which duplicated the first child and was not initialized when the expression is rebuilt bywithChildren, and read the first argument throughgetArgument(0).After the fix, the query above is rejected during analysis with
The bucket of NTILE must be an integer within the range of BIGINT, but got LARGEINT, while an integer bucket (TINYINT/SMALLINT/INT/BIGINT) keeps working as before.None
./run-regression-test.sh --run -f regression-test/suites/query_p0/sql_functions/window_functions/test_ntile_function.groovyWhat problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)