fix: reimplement MySQL type compatibility for 3.0-dev

[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 #24184

What this PR does / why we need it:

This PR reimplements the MySQL type compatibility updates needed by 3.0-dev for issue #24184 without cherry-picking the previous backport commits.

It adds or wires:

• YEAR type basics, parsing, planner mapping, vector function support, and cast execution paths.
• DECIMAL256 parsing/formatting, scientific notation with e+NN, planner literal typing, and string / NULL cast execution paths.
• MySQL SET value normalization/parsing and SHOW type formatting.
• GEOMETRY planner/type mapping and binary charset handling.
• Float overflow behavior for exp() and float addition.
• Focused unit tests for the new type and cast behavior.

Validation:

• make
• make static-check
• go test ./pkg/container/types -count=1
• go test ./pkg/sql/plan -count=1
• go test ./pkg/sql/plan/function -count=1
• go test ./pkg/sql/parsers/dialect/mysql -count=1
• go test ./pkg/compare ./pkg/sort -count=1
• go test ./pkg/frontend -run 'Test.*Year|Test.*Geometry|Test.*Set|TestMysqlProtocol|Test_format|Test_getDataFromPipeline' -count=1
• go test ./pkg/vm/engine/tae/index -run 'Test.*ZM|Test.*Zone' -count=1

[XuPeng-SH]

PR #24204 Review: Reimplement MySQL Type Compatibility for 3.0-dev

Size: +7117 / -3534 across ~50 files

Overview

This PR adds MySQL-compatible support for several type system features:

1. YEAR type (1901-2155, two-digit mapping, int16 storage)
2. SET type (bitmask stored as uint64, up to 64 members)
3. GEOMETRY subtypes (POINT, LINESTRING, POLYGON, etc.)
4. Decimal256 (precision up to 65 digits, scale max 30)
5. Float overflow detection (arithmetic +/-/*/div now rejects Inf)
6. Duplicate-entry error rewriting (shows user-visible column names instead of __mo_index_idx_col)

Strengths

• Excellent test coverage. Every new feature has comprehensive unit tests: cast paths (all integer widths, float rounding, null propagation, overflow rejection), SET member resolution, YEAR range validation, Decimal256 round-trips, float overflow detection, and dup-entry rewriting.
• SET type design is solid. sync.Map descriptor caching, JSON encoding for sets with empty members, bitmask storage as uint64. The buildDefaultExpr / buildOnUpdate paths correctly fold non-literal expressions before SET member resolution.
• Float overflow checks are well-placed. Both scalar and array arithmetic paths detect Inf and return ErrOutOfRange. Exp() also catches overflow.
• Dup-entry rewriting is clean. The regex-based approach with the safety guard for multiple unique indexes (falls back to original error) is the right tradeoff.

Issues

High Priority

1. decimal256ToFloat has a suspicious double-parse (func_cast.go, new decimal256ToFloat function):

   result, err := strconv.ParseFloat(xStr, bitSize)
   if err != nil {
       return moerr.NewOutOfRangef(ctx, "float32", ...)
   }
   if bitSize == 32 {
       result, _ = strconv.ParseFloat(xStr, 64)  // re-parses as float64?
   }

   When bitSize == 32, the first parse validates as float32, then it re-parses as float64 — discarding the error. This is copy-pasted from decimal128ToFloat which has the same pattern, but it looks like a bug in both: for float32 targets you should keep the float32-precision value, not widen to float64. The T(result) cast at the end narrows it back, but the intermediate float64 value may differ from the float32 parse.

2. SET type uses T_uint64 as storage OID. This means any uint64 column with non-empty Enumvalues is treated as a SET. This is fragile — if any other codepath accidentally sets Enumvalues on a uint64 column, it would be misidentified. Consider using a dedicated type OID (like T_set) or at minimum adding a more explicit discriminator.

3. Decimal256 cast matrix is very limited — only float32 and float64 are supported targets:

   types.T_decimal256: {
       types.T_float32, types.T_float64,
   },

   Missing: T_char, T_varchar, T_text, T_decimal64, T_decimal128, integer types. Users will get "unsupported cast" errors for common operations like CAST(decimal256_col AS VARCHAR) or SELECT decimal256_col + int_col. This will likely cause issues in practice. At minimum, string casts should be supported.

4. RewriteHiddenIndexDupEntry with len(uniques) != 1 guard — when a table has multiple unique indexes, the error falls back to the raw __mo_index_idx_col message. This is better than misattributing, but could be improved by extracting the duplicated value and matching it against each index's column set. Worth a TODO.

Medium Priority

5. formatStr behavior change (build_show_util.go) — the function previously escaped all interior single quotes. Now it only escapes quotes inside string literals (detected by leading/trailing '). This is correct for expression defaults like concat('read',''), but verify there's no codepath that passes a bare string value (not wrapped in quotes) that contains an apostrophe — those would now pass through unescaped.

6. Parse256 fallthrough in make.go — when Parse128 fails, the code falls through to Parse256. But Parse128 can fail for reasons other than value too large (e.g., malformed input). In that case, Parse256 will also fail and return its own error, which may be confusing. Consider checking the error type from Parse128 before falling through.

Low Priority

7. Geometry subtypes are all mapped to the same OID (MYSQL_TYPE_GEOMETRY), differentiated only by FamilyString / Enumvalues. Storage layer treats POINT and POLYGON identically. Fine for 3.0-dev scope but should be documented.

8. NormalizeSetValues uses sync.Map for caching parsed descriptors. The cache never shrinks. Not a practical concern given set definitions are per-column and relatively few.

Summary

Well-structured, thoroughly-tested PR that adds significant MySQL type compatibility. Main concerns are: (1) the very limited Decimal256 cast matrix which will hit users in practice, (2) the fragile SET type detection via T_uint64 + Enumvalues, and (3) the suspicious double-parse in decimal256ToFloat. The float overflow detection and dup-entry rewriting are clean wins. Test coverage is notably strong across the board.