jacktengg opened a new pull request, #70518:
URL: https://github.com/apache/doris/pull/70518
Nereids converts arithmetic operands to numeric types during analysis.
String literals can use the other operand's type when conversion succeeds.
Other strings need a CAST expression. CAST evaluation uses enable_strict_cast
to handle invalid input.
Issue Number: None
Related PR: None
PR Type: Bugfix
Problem Summary:
SELECT 'abc' + 1 fails during analysis even when enable_strict_cast=false. A
separate BigDecimal check rejects the value before CAST evaluation. Remove this
check and use the existing CAST rules. The query then returns NULL in
non-strict mode and reports a conversion error in strict mode.
- **Frequency:** Every invalid numeric string literal that reaches the
separate arithmetic check fails during analysis.
- **Root cause:** The value check uses BigDecimal and does not read the CAST
mode. It also rejects spaces that DOUBLE conversion accepts.
- **Why existing tests missed it:** The inspected tests cover explicit CAST
and valid arithmetic. They do not cover invalid string literals at this
arithmetic analysis entry.
- **Fix:** Remove the duplicate value check. Keep numeric type selection and
CAST construction. Add comments with valid and invalid examples.
- **Other paths and branches:** Addition, subtraction, multiplication,
modulo, and bitwise arithmetic share this method. Division and explicit CAST
already use CAST evaluation. The same check exists in tag 2.1.11-rc01. That
version can fall back to the legacy planner, but the reported installation's
planner path is unverified.
- **Behavior change:** Invalid numeric strings now follow the existing CAST
mode. Strict mode still reports an error. Valid DOUBLE text with surrounding
spaces is accepted. Integer strings retain integer arithmetic.
- Before the fix, the new SQL suite fails with the reported 'abc' analysis
error. Both new unit tests fail on the removed check.
- After the fix, build.sh --fe passes with Checkstyle enabled.
- run-fe-ut.sh passes all 99 tests in TypeCoercionUtilsTest,
ExpressionAnalyzerTest, FoldConstantTest, and StringLikeLiteralTest.
- run-regression-test.sh generates the new suite's output. The new suite and
three existing arithmetic and CAST suites then pass against their output files.
- The new SQL suite needs no table or stored data. It checks both operand
positions and CAST modes with FE folding and BE evaluation.
- Direct SQL and EXPLAIN confirm NULL in non-strict mode and conversion
errors in strict mode on the new local FE.
String literal arithmetic now follows enable_strict_cast. For example,
SELECT 'abc' + 1 returns NULL when the setting is false. It reports a
conversion error when the setting is true. Valid DOUBLE text with surrounding
spaces is accepted.
- Behavior changed: Yes (see Details)
- Does this need documentation: No
- Pre-submission status: Ready
- Tool: Codex (GPT-6)
- Generated: Code, comments, tests, analysis, and this description
- Human review: Pending
### Background
<!-- How the feature or module this PR touches works today, in two to four
plain sentences, for a reviewer who doesn't know it. Link the user doc if there
is one. Leave the problem and the fix to Problem Summary. -->
### What problem does this PR solve?
<!-- Issue Number: "close #N" if this PR resolves the issue, "#N" if it only
relates to it, "None" if there is none. A Feature needs an issue. -->
<!-- Related PR: "#N (relation)" for each PR a reviewer should know about,
such as "#123 (introduced the bug)", separated by commas. Write "None" if no
related PR is known. -->
<!-- PR Type: Bugfix, Performance, Feature, Enhancement, Refactor, Test,
Build/CI/Chore, Revert, Release/Dependency, or Other. -->
Issue Number:
Related PR:
PR Type:
Problem Summary:
<!-- Two to five sentences: the problem or need and who is affected; the
approach in one sentence; when the diff is larger than that suggests, what else
it had to handle, or that most of it is tests; and what existing users see
after an upgrade. -->
### Details
<!--
For a diff of more than about 300 changed lines, start with "- **Change
map:**": how many lines are production code, tests, generated files, and docs,
then the code in parts, each with the problem it handles and its size.
Then answer each field of your PR type on its own line, as "- **Field:**
answer", in this order:
Bugfix: Frequency, Root cause, Why existing tests missed it, Fix, Other
paths and branches
Performance: Why it was slow, Optimization, Results, Applicability and cost
Feature: Scope, Design, Usage, Default behavior, Compatibility
Enhancement: Before and after, Configs and defaults, Impact on existing
users
Refactor: Moves vs. logic changes, Behavior change, Compatibility,
Performance impact, Rollback
Test, adding tests: Scenarios, What existing tests miss, Fails when broken
Test, fixing a test: Failure, Cause, Stability evidence
Build/CI/Chore: Affected, Developer and release impact, License and
third-party, Rollback
Revert: Why not fix forward, Original author notified, Follow-up
Release/Dependency: Versions, Upstream changes, Compatibility, Rollback
Other: Why Other
"None" is a valid answer when it is true. Don't restate the diff.
-->
### Testing
<!-- The tests, suites, or commands that ran, what each shows, and where it
ran (locally or in CI). For a fix, the test that fails before it and passes
after. -->
### Notes for Reviewers
<!-- Optional; delete this section if there is nothing to say. Why each
non-obvious edit was made, what you are unsure about, and where to start
reading if Details has no Change map. -->
### Release note
<!-- One paragraph on what users will notice, or None. -->
### Check List (For Author)
<!-- Behavior changed: "No", or "Yes (see Details)" with a Behavior change
field in Details. -->
<!-- Does this need documentation: "No", or "Yes" with the
apache/doris-website PR or the plan. -->
<!-- Pre-submission status: "Ready"; "Partially verified: " and what is not
verified; or "Not ready: " and why, for a Draft PR. -->
- Behavior changed:
- Does this need documentation:
- Pre-submission status:
### AI Disclosure
<!-- Tool: the agent and model, or None. Generated: the parts it wrote
(code, tests, this description), or None. Human review: what you reviewed of
the generated parts, or "Not applicable" without AI tools. You may add "-
Prompts:" to summarize how you directed the agent. -->
- Tool:
- Generated:
- Human review:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
