Skip to content

[BugFix] Fix type mismatch in map literal when explicit key/value types are declared (backport #71316)#71345

Merged
wanpengfei-git merged 2 commits intobranch-4.1from
mergify/bp/branch-4.1/pr-71316
Apr 7, 2026
Merged

[BugFix] Fix type mismatch in map literal when explicit key/value types are declared (backport #71316)#71345
wanpengfei-git merged 2 commits intobranch-4.1from
mergify/bp/branch-4.1/pr-71316

Conversation

@mergify
Copy link
Copy Markdown
Contributor

@mergify mergify bot commented Apr 7, 2026

Why I'm doing:

Fix https://github.com/StarRocks/StarRocksTest/issues/11202

When a map literal is written with an explicit type annotation (e.g., map<smallint, smallint>{1: 2, 3: 4}), the FE analyzer failed to cast the child expressions (key/value literals) to the declared key and value types.
Integer literals like 1, 2, 3, 4 are inferred as TINYINT by default. Because visitMapExpr only handled the implicit-type case (AnyMapType.ANY_MAP) and had no logic for the explicit-type case, the children retained their inferred TINYINT types. These mistyped expressions were then serialized and sent to the BE.
On the BE side, MapExpr::evaluate_checked cloned the key column as a FixedLengthColumn<int8_t> (1 byte), but later attempted to append it into a FixedLengthColumnBase<int16_t> (2 bytes), causing a heap-buffer-overflow detected by
AddressSanitizer.

A typical reproducer:

  ALTER TABLE t ADD COLUMN c MAP<SMALLINT, SMALLINT>
  DEFAULT map<smallint, smallint>{1: 2, 3: 4};                                                                                                                                                                                          
                                              
  SELECT id, c FROM t ORDER BY id;  -- crashes BE       

Root Cause

In ExpressionAnalyzer.visitMapExpr, when the map has an explicit MapType (not AnyMapType.ANY_MAP), no casting was applied to the child expressions. The declared key/value types were simply ignored, and children kept their own inferred types.

The same issue did not exist for ArrayExpr — visitArrayExpr already correctly casts children to the declared item type when an explicit array type is present.

Fix

When the map literal has an explicit type, extract the declared keyType and valueType from the MapType and cast each key/value child expression to the corresponding type if it doesn't already match — exactly mirroring the existing pattern in visitArrayExpr.

What I'm doing:

Fix type mismatch in map literal when explicit key/value types are declared

What type of PR is this:

  • BugFix
  • Feature
  • Enhancement
  • Refactor
  • UT
  • Doc
  • Tool

Does this PR entail a change in behavior?

  • Yes, this PR will result in a change in behavior.
  • No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

  • Interface/UI changes: syntax, type conversion, expression evaluation, display information
  • Parameter changes: default values, similar parameters but with different default values
  • Policy changes: use new policy to replace old one, functionality automatically enabled
  • Feature removed
  • Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

  • I have added test cases for my bug fix or my new feature
  • This pr needs user documentation (for new or modified features or behaviors)
    • I have added documentation for my new feature or new function
    • This pr needs auto generate documentation
  • This is a backport pr

Bugfix cherry-pick branch check:

  • I have checked the version labels which the pr will be auto-backported to the target branch
    • 4.1
    • 4.0
    • 3.5
    • 3.4

This is an automatic backport of pull request #71316 done by [Mergify](https://mergify.com).

…es are declared (#71316)

Signed-off-by: trueeyu <[email protected]>
(cherry picked from commit fdc3329)

# Conflicts:
#	fe/fe-core/src/test/java/com/starrocks/sql/analyzer/ExpressionAnalyzerTest.java
#	test/sql/test_map/R/test_map
@mergify
Copy link
Copy Markdown
Contributor Author

mergify bot commented Apr 7, 2026

Cherry-pick of fdc3329 has failed:

On branch mergify/bp/branch-4.1/pr-71316
Your branch is up to date with 'origin/branch-4.1'.

You are currently cherry-picking commit fdc3329597.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   fe/fe-core/src/main/java/com/starrocks/sql/analyzer/ExpressionAnalyzer.java
	modified:   fe/fe-core/src/test/java/com/starrocks/sql/analyzer/AnalyzeExprTest.java
	modified:   test/sql/test_default_value/R/test_complex_default_all_paths.sql
	modified:   test/sql/test_default_value/T/test_complex_default_all_paths.sql

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   fe/fe-core/src/test/java/com/starrocks/sql/analyzer/ExpressionAnalyzerTest.java
	both modified:   test/sql/test_map/R/test_map

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

@mergify mergify bot added the conflicts label Apr 7, 2026
@wanpengfei-git wanpengfei-git enabled auto-merge (squash) April 7, 2026 04:02
@mergify mergify bot closed this Apr 7, 2026
auto-merge was automatically disabled April 7, 2026 04:03

Pull request was closed

@mergify
Copy link
Copy Markdown
Contributor Author

mergify bot commented Apr 7, 2026

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr

@trueeyu trueeyu reopened this Apr 7, 2026
@wanpengfei-git wanpengfei-git enabled auto-merge (squash) April 7, 2026 05:44
Signed-off-by: trueeyu <[email protected]>
@wanpengfei-git wanpengfei-git merged commit 329bb2f into branch-4.1 Apr 7, 2026
36 of 37 checks passed
@wanpengfei-git wanpengfei-git deleted the mergify/bp/branch-4.1/pr-71316 branch April 7, 2026 07:32
@tiannan-sr
Copy link
Copy Markdown

@Mergifyio backport branch-4.1.0

@mergify
Copy link
Copy Markdown
Contributor Author

mergify bot commented Apr 7, 2026

backport branch-4.1.0

✅ Backports have been created

Details

mergify bot added a commit that referenced this pull request Apr 7, 2026
…es are declared (backport #71316) (#71345)

Signed-off-by: trueeyu <[email protected]>
Co-authored-by: trueeyu <[email protected]>
(cherry picked from commit 329bb2f)
wanpengfei-git pushed a commit that referenced this pull request Apr 7, 2026
…es are declared (backport #71316) (backport #71345) (#71373)

Signed-off-by: trueeyu <[email protected]>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: trueeyu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants