fix: align INSERT/UPDATE string width enforcement with MySQL sql_mode (#25200) (cherry-pick #25262)

[ck89119]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #25200

What this PR does / why we need it:

Cherry-pick of PR #25262 from 3.0-dev to main.

Rework CHAR/VARCHAR width enforcement on DML assignment paths so it matches MySQL's sql_mode semantics:

• sql_mode gating (runtime): add a new cast_assign function used by DML assignment paths for CHAR/VARCHAR targets. It reads sql_mode at runtime (strict -> reject 1406, non-strict -> truncate), avoiding plan-cache staleness.
• trailing-space exemption: over-length values whose excess is only trailing spaces are accepted (truncated) even under strict mode, matching MySQL.
• INSERT IGNORE downgrade: under IGNORE, over-length writes are truncated instead of rejected.

Notes

• func_cast.go and func_cast_test.go were taken from the 3.0-dev version. Main-specific functions in these files may need review.
• build_test.go changes were not included in this cherry-pick due to significant divergence from feat(insert): align ON DUPLICATE KEY UPDATE with MySQL, drop legacy operator #24973.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[XuPeng-SH]

Requesting changes.

The cherry-pick fixes the local/plan-level blockers I raised on #25262: INSERT IGNORE is now threaded through the non-literal VALUES path, prepared literal VALUES now route through a volatile runtime cast instead of freezing the plan-time decision, VARBINARY is no longer relaxed by the CHAR/VARCHAR constant path, and the fallback buildInsert initializes isInsertIgnore. CI is green and the new BVT covers the main single-CN SQL matrix.

I still see one correctness blocker in the current design: cast_assign reads sql_mode from the local process.Process resolver at execution time, but remote-run processes do not carry that resolver or an encoded sql_mode value. That means the same assignment cast can behave as strict on a remote CN even when the user session is non-strict.

Relevant paths:

• pkg/sql/plan/function/func_cast.go:458-459: NewAssignCast calls isStrictSqlMode(proc) at function execution time.
• pkg/sql/plan/function/func_cast.go:467-469: if proc.GetResolveVariableFunc() is nil, isStrictSqlMode returns true.
• pkg/sql/compile/remoterunClient.go:182-195: remote run sends the encoded scope plus encoded process info.
• pkg/vm/process/process_codec.go:92-102: encoded pipeline.SessionInfo includes user/host/db/version/timezone/query id/lock timeout, but not sql_mode and not a resolver.
• pkg/sql/compile/remoterunServer.go:398-415: the remote CN rebuilds a fresh process.Process, restores SessionInfo, and does not install any ResolveVariableFunc.

The existing remote var-expression mechanism does not close this gap: foldVarExprsInRemoteRunScope only folds explicit plan.Expr_V variables before encoding (pkg/sql/compile/remote_expr.go:51-118). cast_assign hides the sql_mode dependency inside the function implementation, so the scope does not contain a var expr to fold.

This matters for assignment paths that can be executed inside remote scopes, e.g. distributed INSERT ... SELECT / UPDATE plans where the projection contains the new cast_assign. In non-strict mode, local execution truncates, while a remote CN with nil resolver will take the strict fallback and return 1406. The current BVT covers the SQL semantics, but not this remote-process boundary.

Suggested fix: make the strictness input explicit and portable across remote execution. For example, either encode the session sql_mode into the remote ProcessInfo / SessionInfo and have isStrictSqlMode fall back to that, or model sql_mode as an explicit expression/input to the assignment cast so the existing remote var-folding path can capture the current execution value. Please also add coverage for the remote/multi-CN path: non-strict INSERT ... SELECT with over-width CHAR/VARCHAR should truncate on a remote execution path, and strict mode should still reject.

Local validation I ran on the current PR head:

go test -ldflags="-extldflags '-L$(pwd)/cgo -lmo -L$(pwd)/thirdparties/install/lib -Wl,-rpath,@executable_path/lib'" \
  -v -count=1 -timeout 120s ./pkg/sql/plan/function \
  -run 'Test(StrToStrWidthEnforcement|OverLenIsAllTrailingSpaces|IsStrictSqlMode|NewAssignCastHonorsSqlMode|strToStr_StrictStringWidth|strToStr_TextToCharVarchar)'
PASS

go test -ldflags="-extldflags '-L$(pwd)/cgo -lmo -L$(pwd)/thirdparties/install/lib -Wl,-rpath,@executable_path/lib'" \
  -v -count=1 -timeout 120s ./pkg/sql/plan \
  -run 'Test(InsertSelectVarcharFromTextUsesAssignmentCast|OnDuplicateUpdateVarcharFromTextUsesAssignmentCast|MakeInsertValueConstExprGeometry)'
PASS