planner: address collation ambiguity in scalar function construction during predicate simplification.

[dash12653]

What problem does this PR solve?

Issue Number: close #56479

Problem Summary:

What changed and how does it work?

We can simplify the sql as follows:

DROP TABLE t1;

CREATE TABLE `t1` (
  `c1` VARCHAR(175) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'asMF'
);

SELECT * 
FROM t1 
WHERE c1 BETWEEN 'string1' AND 'string2' AND (c1 = 'string3' OR IsNull(c1));

When rewriting the BETWEEN and AND clause, the collations of string1 and string2 will be set to c1's collation—utf8mb4_unicode_ci rather than collation_connection.

During predicate simplification, a scalar function 'ge' will be constructed using string1 and string3 as parameters. However, since string1 has a collation of utf8mb4_unicode_ci and string3 has a collation of utf8mb4_general_ci (collation_connection), and both of them have a coercibility of 4, there is ambiguity regarding which collation to use. This leads to an failure to construct a new scalar function, which will lead a panic.

There's an additional concern: if we replace "BETWEEN and AND" with "<= and >=", then both string1 and string3 have a collation of utf8mb4_general_ci(collation_connection), then during predicate simplification, string1 and string3 would be compared using the utf8mb4_general_ci collation. This might lead to potential incorrect results.

Maybe we can:

During predicate simplification, we could reset the collation of the constants (string1, string2, string3) to match the collation of the column c1 to address the problems.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

Hi @dash12653. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions 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/test-infra repository.

[tiprow]

Hi @dash12653. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions 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.

[AilinKid]

why should we set it back? it has not changed?

[dash12653]

In the WHERE clause : WHERE c1 BETWEEN 'string1' AND 'string2' AND (c1 = 'string3' OR IsNull(c1)), 'string1' and 'string2' are set to the column's collation (utf8mb4_unicode_ci) when rewriting BETWEEN ... AND, but 'string3' is set to the connection-level collation (utf8mb4_general_ci). Before comparing "string1" and "string3" here, to avoid such collation mismatches, I explicitly reset the collations for the string constants.

[AilinKid]

we have a deriveCollation(ctx, funcName, args, retType, retType) inside, which serves collation mismatch, while it's embedded in cast function, so i guess the better way here is to build a wrapper cast function BuildCastFunction as L237's new child but not for sure, you can have a try

[dash12653]

Thanks for the clarification! I’ll check out deriveCollation and try building a wrapper cast function like BuildCastFunction as you suggested.

[AilinKid]

sorry, after discussion with @time-and-fate , seems we could use his suggested way, which will be more clear.

[AilinKid]

@dash12653 hi, thanks for your contribution, do you mind having some updates for this pull request recently, we are lanching planner-related issue resolution campaign

[time-and-fate]

Considering the problem in the case is actually an error from NewFunction but ignored, I would suggest changing the existing NewFunctionInternal to NewFunction and correctly handling the error.

[dash12653]

@dash12653 hi, thanks for your contribution, do you mind having some updates for this pull request recently, we are lanching planner-related issue resolution campaign

Thanks for letting me know! I’ll update the PR accordingly. Let me know if you need anything else.

[dash12653]

Considering the problem in the case is actually an error from NewFunction but ignored, I would suggest changing the existing NewFunctionInternal to NewFunction and correctly handling the error.

Thanks for the feedback! Just to clarify, are you suggesting that I should only update the function use and handle the error, and that my previous changes can be discarded?

[time-and-fate]

Considering the problem in the case is actually an error from NewFunction but ignored, I would suggest changing the existing NewFunctionInternal to NewFunction and correctly handling the error.

Thanks for the feedback! Just to clarify, are you suggesting that I should only update the function use and handle the error, and that my previous changes can be discarded?

Yes.
Probably we can be smarter in handling collation mismatch, but it's not quite an appropriate place to add new logic to handle collation mismatch here.
If we focus on the bug itself, the direct reason is that: the error inside NewFunctionInternal is ignored and the returning nil remains unhandled, then goes into the next step, causing panic. Besides, NewFunctionInternal is also marked deprecated.
So, for this bug, I think it's better to switch to using NewFunction and handle the error.

[time-and-fate]

/ok-to-test

[dash12653]

Considering the problem in the case is actually an error from NewFunction but ignored, I would suggest changing the existing NewFunctionInternal to NewFunction and correctly handling the error.

Thanks for the feedback! Just to clarify, are you suggesting that I should only update the function use and handle the error, and that my previous changes can be discarded?

Yes. Probably we can be smarter in handling collation mismatch, but it's not quite an appropriate place to add new logic to handle collation mismatch here. If we focus on the bug itself, the direct reason is that: the error inside NewFunctionInternal is ignored and the returning nil remains unhandled, then goes into the next step, causing panic. Besides, NewFunctionInternal is also marked deprecated. So, for this bug, I think it's better to switch to using NewFunction and handle the error.

Got it. I’ll try NewFunction and handling the error.

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 3 lines in your changes missing coverage. Please review.

Project coverage is 74.7315%. Comparing base (ef8cac2) to head (10ab2c3).
Report is 15 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #57049        +/-   ##
================================================
+ Coverage   72.8597%   74.7315%   +1.8718%     
================================================
  Files          1672       1717        +45     
  Lines        462630     470817      +8187     
================================================
+ Hits         337071     351849     +14778     
+ Misses       104795      96851      -7944     
- Partials      20764      22117      +1353     

Flag	Coverage Δ
integration	49.2614% <66.6666%> (?)
unit	72.2556% <33.3333%> (+0.0070%)	⬆️

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

Components	Coverage Δ
dumpling	52.7673% <ø> (ø)
parser	∅ <ø> (∅)
br	60.6787% <ø> (+15.5530%)	⬆️

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[dash12653]

/retest

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AilinKid, time-and-fate

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [AilinKid,time-and-fate]
• pkg/planner/OWNERS [AilinKid,time-and-fate]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-11-17 14:08:36.649149589 +0000 UTC m=+797278.840018586: ☑️ agreed by time-and-fate.
• 2024-11-18 03:59:00.674173863 +0000 UTC m=+847102.865042860: ☑️ agreed by AilinKid.

[fixdb]

/retest

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-8.5: #57476.