[CALCITE-7607] DML type coercion inserts implicit narrowing casts for target-column assignments by zzwqqq · Pull Request #5041 · apache/calcite

zzwqqq · 2026-06-23T09:25:53Z

Jira Link

Changes Proposed

Avoid adding implicit narrowing casts for DML assignments when the source type can be assigned to the target type.

The validator no longer adds these casts during DML source coercion, and TableModify#getExpectedInputRowType is adjusted so CoerceInputsRule does not add them back later.

Added tests for INSERT, UPDATE, and MERGE, and updated existing plan output where these assignment casts used to appear.

… target-column assignments

sonarqubecloud · 2026-06-23T09:40:05Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

xuzifu666 · 2026-06-23T11:33:28Z


 # Create a source table
-create table dept (deptno int not null, name varchar(10));
+create table dept (deptno int not null, name varchar(20));


Could you provide a specific SQL test and compare the results? You can add relevant comments here.

Thanks for taking a look. The old output depended on the implicit assignment cast to varchar(10), which truncated Engineering to Engineerin.

That truncation is not what this test is intended to cover, so I widened the column to keep the test focused on CREATE TABLE AS/MV behavior.

But was the behavior incorrect?
What is the new behavior if you don't change the type?

With either varchar(10) or varchar(20), the new output is Engineering, not Engineerin, because the implicit narrowing cast is no longer added.

I widened the column because I wanted to avoid implying that over-length inserts into varchar(10) are intended here

What is the correct behavior if the type is varchar(10)?
There must be a spec or a reference that has to match in behavior.

I tested this in PostgreSQL, MySQL and Oracle, and they all reject inserting an over-length value.
https://onecompiler.com/postgresql/44sf3dz68
https://onecompiler.com/mysql/44sf3efz4
https://onecompiler.com/oracle/44sf3ewmh

That is good. But is there code in the handling of assignments in Calcite which will perform the rejection?
Is this in scope for this PR or does it need another issue?
This also suggests that casts should not be inserted, since they would transform illegal values into legal ones.

I couldn’t find any Enumerable-side code that rejects over-length values. My current view is that adding that enforcement would be a separate issue from this PR.

Can you please file an issue about this and perhaps even refer to it in your code if the results are currently wrong?

Sure, I filed CALCITE-7627 to track the Enumerable-side case, and I can look into it separately after this pr.
The results are currently correct, because I widened the column.

xuzifu666 · 2026-06-23T11:34:24Z

    HepProgram program = new HepProgramBuilder()

-        // Simulate the way INSERT will insert casts to the target types
+        // Simulate the way INSERT can insert casts to the target types.


I don't understand why this comment needs to be changed.

I changed it because CoerceInputsRule may now decide not to add a cast. I can revert this comment if you think it is better to avoid the unrelated diff.

xuzifu666 · 2026-06-23T11:35:51Z

              + "empid=[$t3], deptno=[$t4], name=[$t5], salary=[$t6], "
              + "commission=[$t7])\n"
-              + "    EnumerableValues(tuples=[[{ 'Fred', 56, 123.4000015258789E0 }]])\n";
+              + "    EnumerableValues(tuples=[[{ 'Fred', 56, 123.4 }]])\n";


These variations in precision may also require an explanation.

The original SQL uses 123.4. The old plan cast the value through a narrower floating-point type, which produced 123.4000015258789E0; without that cast the value stays 123.4.

mihaibudiu · 2026-06-27T04:16:04Z

 !update

-# Check contents; "Engineering" is too long for varchar(10)
+# Check contents


So you say this test should produce an error rather than truncating the string?

Yes, I think it should fail rather than truncate.

mihaibudiu

I think these changes make sense, but they do uncover a separate issue: updating with a value out of range should produce a runtime error rather than a silent cast which may lose data.

[CALCITE-7607] DML type coercion inserts implicit narrowing casts for…

1722831

… target-column assignments

xuzifu666 reviewed Jun 23, 2026

View reviewed changes

mihaibudiu reviewed Jun 27, 2026

View reviewed changes

mihaibudiu approved these changes Jun 27, 2026

View reviewed changes

Uh oh!

Conversation

zzwqqq commented Jun 23, 2026

Jira Link

Changes Proposed

Uh oh!

sonarqubecloud Bot commented Jun 23, 2026

Quality Gate passed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zzwqqq Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mihaibudiu left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zzwqqq Jun 23, 2026 •

edited

Loading