expr: apply target length/truncation to JSON-to-CHAR cast pushdown - #20041
expr: apply target length/truncation to JSON-to-CHAR cast pushdown#20041NasitSony wants to merge 1 commit into
Conversation
Fixes tikv#19883 cast_json_as_bytes captured only EvalContext and returned the full converted JSON string unconditionally, with no length or truncation handling. TiDB's builtinCastJSONAsStringSig applies ProduceStrWithSpecifiedTp using the return FieldType's flen, which can truncate the result or, under strict mode, abort the statement for an overlong value. Since this conversion backs predicates and DML pushed down to the coprocessor (e.g. CAST(json_col AS CHAR(n)) <> value), a query could select or mutate different rows than the same statement evaluated at the TiDB root -- in the reported case, a DELETE using an overlong cast value removed rows that TiDB's root evaluation would have aborted before touching. Added extra: &RpnFnCallExtra to cast_json_as_bytes's capture list and routed the converted value through the existing cast_as_string_helper (already used by cast_string_as_string), which applies produce_str_with_specified_tp -- the same flen-based truncation/error logic TiDB uses. This is a pure wiring fix: ret_field_type was already transported via RpnFnCallExtra, just not consumed by this function. Added a regression test using the exact reproduction value (1234.5 cast to CHAR(4)), confirming it now errors under strict mode rather than silently truncating. Signed-off-by: Nasit Sarwar Sony <nasitsony96@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @NasitSony. Thanks for your PR. I'm waiting for a tikv member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthrough
ChangesJSON string cast behavior
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This is a localized fix to make pushed-down JSON-to-CHAR casts honor target length and strict-mode errors; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Linked Issues checkExplanation The changes address issue ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes #19883
cast_json_as_bytes captured only EvalContext and returned the full converted JSON string unconditionally, with no length or truncation handling. TiDB's builtinCastJSONAsStringSig applies ProduceStrWithSpecifiedTp using the return FieldType's flen, which can truncate the result or, under strict mode, abort the statement for an overlong value. Since this conversion backs predicates and DML pushed down to the coprocessor (e.g. CAST(json_col AS CHAR(n)) <> value), a query could select or mutate different rows than the same statement evaluated at the TiDB root -- in the reported case, a DELETE using an overlong cast value removed rows that TiDB's root evaluation would have aborted before touching.
Added extra: &RpnFnCallExtra to cast_json_as_bytes's capture list and routed the converted value through the existing cast_as_string_helper (already used by cast_string_as_string), which applies produce_str_with_specified_tp -- the same flen-based truncation/error logic TiDB uses. This is a pure wiring fix: ret_field_type was already transported via RpnFnCallExtra, just not consumed by this function.
Added a regression test using the exact reproduction value (1234.5 cast to CHAR(4)), confirming it now errors under strict mode rather than silently truncating.
What is changed and how it works?
Issue Number: Close #19883
What's Changed:
Related changes
pingcap/docs/pingcap/docs-cn:Check List
Tests
Side effects
Release note
Summary by CodeRabbit