MDEV-33010 Condition with CHARSET()/COERCIBILITY() erroneously pushed… #3167
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… into derived table Based on the current logic, objects of classes Item_func_charset and Item_func_coercibility (responsible for CHARSET() and COERCIBILITY() functions) are always considered const. However, SQL syntax allows their use in a non-constant manner, such as CHARSET(t1.a), COERCIBILITY(t1.a), and similar. This "const-forcing" was introduced with commit aa1002a. When those objects are erroneously deemed const, it could lead to unwanted consequences like pushing down conditions to materialized derived tables illegitimately. This commits removes the "const-forcing" for Item_func_charset and Item_func_coercibility, making them determine their constness in the general way
|
Good catch, the fix makes sense and the accompanying test seems to accurately depict the scenario you are describing in your description. |
anson1014
approved these changes
Apr 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… into derived table
Based on the current logic, objects of classes Item_func_charset and Item_func_coercibility (responsible for CHARSET() and COERCIBILITY() functions) are always considered const.
However, SQL syntax allows their use in a non-constant manner, such as CHARSET(t1.a), COERCIBILITY(t1.a), and similar.
This "const-forcing" was introduced with
commit aa1002a.
When those objects are erroneously deemed const, it could lead to unwanted consequences like pushing down conditions to materialized derived tables illegitimately.
This commits removes the "const-forcing" for Item_func_charset and Item_func_coercibility, making them determine their constness in the general way
Release Notes
TODO: What should the release notes say about this change?
Include any changed system variables, status variables or behaviour. Optionally list any https://mariadb.com/kb/ pages that need changing.
How can this PR be tested?
TODO: modify the automated test suite to verify that the PR causes MariaDB to behave as intended.
Consult the documentation on "Writing good test cases".
If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.
Basing the PR against the correct MariaDB version
PR quality check