Repository navigation
[core] Validate aggregate function types at DDL time #10983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
JingsongLi
merged 1 commit into
apache:master
from
ZZZxDong:fix/aggregate-type-check-on-ddl
Nov 6, 2026
+228
−3
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[P1] Keep valid historical projections readable after aggregate schema evolution
AbstractFileStoreTable.runtimeStore()also runs this check, before the read projection is applied. I created a primary-key partial-update table withlabel VARCHAR(16)protected byfields.seq.sequence-group=label, wrote snapshot 1, and widenedlabeltoSTRINGwhile enablinglistaggthrough ALTER. Both DDL operations succeed. A read of onlyidat snapshot 1 passes on the base and now fails before planning withlist agg column must be STRING ... VARCHAR(16), because time travel combines the old type with current options. The same eager check also blocks previously working projections on pre-upgrade tables with incompatible aggregators on unused columns. Please run the eager type check on CREATE/ALTER and preserve the runtime projection behavior for stored schemas. Add the historical projection as a regression test.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed — I'll restrict the eager check to the CREATE/ALTER schema-commit path so reads of stored schemas keep the previous projection-scoped behavior, and add a regression test for the time-travel projection you described.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied both points in bd984a2: the eager type check now runs only from
FileSystemSchemaManager.commit()so stored schemas keep the previous projection-scoped read behavior, andTimeTravelSchemaEvolutionTest#testTimeTravelProjectionWithEvolvedAggregateFunctioncovers theVARCHAR(16)→STRING+listaggscenario you described (verified it fails without the change).