mysql/json: read character data's numbers as the double MySQL stores

[arthurschreiber]

Description

Stacked on #20722 and #20723 — only the last commit is new here; the base retargets down the stack as those merge.

#20722 made Vitess agree with MySQL on which JSON documents exist. This one makes it agree on what their numbers are worth. MySQL parses JSON numbers at normal precision (significand accumulated into a double, one multiplication to scale it), so for long significands and large exponents its stored double sits an ULP or two away from the correctly-rounded one Vitess produced — for 17+ significant digits that's a majority of numbers, so the same expression could produce a different value evaluated in vtgate than pushed down.

The parser gains ParseCast/ParseCastBytes, which read numbers with the same conversion the validity check already transcribes, now returning the value. A float's kind settles at parse time, in keeping with #20723 — reading a value never writes back, and the mode is per-call, so a pooled parser cannot carry one caller's choice into the next parse. Where the cast reading applies is decided by one question: what would mysqld do with the same bytes?

• Character data — CAST(... AS JSON), string arguments to JSON functions, and JSON-typed bind variables — gets MySQL's conversion, because mysqld would parse that text with its document parser (a parameter can't reach mysqld any other way).
• JSON columns keep the exact reading: their wire text spells the double the tablet's mysqld already holds, and correct rounding reconstructs it losslessly. Re-reading printed text MySQL's way would move roughly a third of doubles by an ULP, which is why this isn't applied wholesale.

Decimal() on a float now derives from the double's shortest round-trip text, which is what MySQL's double2decimal does (it prints through my_gcvt and reads the digits back) — with that, JSON comparisons, hashing and weight strings all follow the stored double with no changes of their own.

Verified over 4,649 documents against real MySQL 8.0.45, 8.4.11 and 9.4.0 on arm64 plus 8.4.11 on x86_64: zero validity or value mismatches, and bit-exact agreement with MySQL's vendored RapidJSON compiled the way MySQL builds it. The expected bits in the tests were confirmed inside the servers with JSON_EXTRACT(...) = CAST(... AS DOUBLE) probes.

Backport justification: on a supported release, the same expression answers differently depending on whether it runs in vtgate or is pushed down to MySQL — the divergence this PR removes is itself the bug, and it bites hardest when one query mixes both, like a scatter query with vtgate-side post-processing over documents MySQL parsed. Values move only for numbers with 16+ significant digits or extreme exponents, the same class whose validity #20722 already changes on those branches.

Related Issue(s)

Same class as #20720/#20724, in the value rather than in whether the document is valid. Stacked on #20722 and #20723.

Checklist

• "Backport to:" labels have been added if this change should be back-ported to release branches
• If this change is to be back-ported to previous releases, a justification is included in the PR description
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on CI?
• Documentation was added or is not required

Deployment Notes

User-visible: numbers with 16+ significant digits or large exponents in JSON built from character data convert, compare, hash and print by MySQL's double instead of the nearest one. Numbers with up to 15 significant digits and moderate exponents don't move, and JSON column values are unaffected. Release note included in changelog/25.0/25.0.0/summary.md.

AI Disclosure

This PR was written primarily by Claude Code — investigation, implementation and tests — with direction and review from me.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[codecov]

Codecov Report

❌ Patch coverage is 84.37500% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.40%. Comparing base (770f8c7) to head (67b1fd0).
⚠️ Report is 1 commits behind head on arthur/json-immutable-values.

Files with missing lines	Patch %	Lines
go/mysql/json/parser.go	80.95%	8 Missing ⚠️
go/vt/vtgate/evalengine/eval.go	87.50%	1 Missing ⚠️
go/vt/vtgate/evalengine/expr_bvar.go	50.00%	1 Missing ⚠️

Additional details and impacted files

@@                        Coverage Diff                        @@
##           arthur/json-immutable-values   #20726       +/-   ##
=================================================================
+ Coverage                         73.00%   86.40%   +13.40%     
=================================================================
  Files                                 6       65       +59     
  Lines                              1715    20918    +19203     
=================================================================
+ Hits                               1252    18075    +16823     
- Misses                              463     2843     +2380     

Flag	Coverage Δ
partial	86.40% <84.37%> (+13.40%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[GrahamCampbell]

We should distinguish client parameters from internally generated bind variables here. A TypeJSON bind variable is not always character-origin: UncorrelatedSubquery, for example, wraps a typed result row with:

combinedVars[ps.SubqueryResult] =
    sqltypes.ValueBindVariable(result.Rows[0][0])

If that result is a JSON column, its text already spells the stored binary-JSON double exactly. Running it through ParseCastBytes can round it again; -5.3746011104623175e107, for example, moves from 0xd64d4ae72831c4f2 to 0xd64d4ae72831c4f3.

The cast-style parsing should happen specifically at the external-parameter boundary, while bind variables synthesized from typed result rows retain the exact/printed parsing path.

[github-actions]

This PR is being marked as stale because it has been open for 30 days with no activity. To rectify, you may do any of the following:

• Push additional commits to the associated branch.
• Remove the stale label.
• Add a comment indicating why it is not stale.

If no action is taken within 7 days, this PR will be closed.