vitess
vitess copied to clipboard
bugfix: Normalizing literals in SELECT is broken
Description
Vitess does auto-parameterization of queries. This means replacing literal values with arguments, so that a plan cache can be re-used between queries, if the only difference is the literal value.
Sometimes, this rewrite messes with queries, such as in the issue reported below.
In this PR, I wanted to stop the Normalizer from rewriting expressions if they are inside unalised select expressions.
To do that, first I needed to clean up our AST a little bit.
Back in the days, we used FuncExpr for all expressions, including count(*). Since then, we have replaced most functions with custom AST types (such as CountStar), and this means that we no longer need to parse * as an argument to a function call.
Using pure expressions simplifies a lot of code and makes it possible to know that when we are looking at an *sqlparser.AliasedExpr, we know we are in the SELECT clause and nowhere else.
Related Issue(s)
Fixes #15020
Checklist
- [x] "Backport to:" labels have been added if this change should be back-ported to release branches
- [x] If this change is to be back-ported to previous releases, a justification is included in the PR description
- [x] Tests were added or are not required
- [x] Did the new or modified tests pass consistently locally and on CI?
- [x] Documentation was added or is not required
Deployment Notes
Review Checklist
Hello reviewers! :wave: 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
Jobsshould be named in order to mark it asrequired. - [ ] 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
_vttables 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.
- [ ]
vtctlcommand output order should be stable andawk-able.
@GuptaManan100 I don't know how to handle this. I think our old way of parsing was hiding an invalid parse output
select 'a' 'b'
was being parsed as
select 'a' as b
but if we look at how mysql treats it, we see this:
mysql> explain select 'a' 'b';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)
mysql> show warnings;
+-------+------+-----------------------------------+
| Level | Code | Message |
+-------+------+-----------------------------------+
| Note | 1003 | /* select#1 */ select 'ab' AS `a` |
+-------+------+-----------------------------------+
1 row in set (0.00 sec)
Needs a backport to 19.0 label?
Needs a backport to 19.0 label?
Not sure we want to backport this. @deepthi @harshit-gangal wdyt?
Codecov Report
Attention: 11 lines in your changes are missing coverage. Please review.
Comparison is base (
4e31f60) 67.29% compared to head (08cabf1) 67.27%.
Additional details and impacted files
@@ Coverage Diff @@
## main #15043 +/- ##
==========================================
- Coverage 67.29% 67.27% -0.02%
==========================================
Files 1560 1560
Lines 192123 192109 -14
==========================================
- Hits 129283 129249 -34
- Misses 62840 62860 +20
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Not sure we want to backport this. @deepthi @harshit-gangal wdyt?
I feel like we should given this is a bug fix, but i have no strong opinions.
EDIT: I think we should also backport to release-18.0, the linked issue (https://github.com/vitessio/vitess/issues/15020) was using v18.0.1.
Needs a backport to 19.0 label?
Not sure we want to backport this. @deepthi @harshit-gangal wdyt?
some part of it is regression from v17 and some are new support. So, we should backport it till v18