MySQL: Add support for SELECT modifiers#2172
Merged
iffyio merged 2 commits intoapache:mainfrom Feb 5, 2026
Merged
Conversation
460f829 to
a437a32
Compare
iffyio
reviewed
Jan 29, 2026
src/parser/mod.rs
Outdated
Comment on lines
14060
to
14061
| let mut distinct: Option<Distinct> = None; | ||
| let mut has_all = false; |
Contributor
There was a problem hiding this comment.
Can we instead introduce a proper enum to represent the three states? the current impl I think is harder to follow which combinations are valid and if/when the specified option is ignored in the output.
Contributor
Author
There was a problem hiding this comment.
Yeah, sure. Is this what you have in mind?
enum Distinct {
All,
Distinct,
On(Vec<Expr),
}I'll go ahead and implement that, but let me know if you had something else in mind that I'll be happy to update it..
Contributor
Author
There was a problem hiding this comment.
lmk what you think. I also reworked it a bit so that DISTINCTROW aliasing only happens here and not in the main parse_all_or_distinct which I believe addresses your other comment.
Previously, `SELECT ALL` was parsed but the ALL keyword was discarded, with `one_statement_parses_to` tests verifying it normalized away. Now the parser returns `Distinct::All` so the AST represents the original SQL. Also improves error messages for conflicting ALL/DISTINCT to indicate which keyword came first.
Adds support for MySQL-specific `SELECT` modifiers that appear after the
`SELECT` keyword. Grammar from the [docs]:
```sql
SELECT
[ALL | DISTINCT | DISTINCTROW ]
[HIGH_PRIORITY]
[STRAIGHT_JOIN]
[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
[SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr [, select_expr] ...
```
Manual testing shows that these options can appear in any order relative
to each other, so for the sake of fidelity, we parse this separately
from how we parse distinct and other options for other dialects, in a
new `Parser::parse_select_modifiers` method.
`DISTINCTROW` is a legacy (but not deprecated) synonym for `DISTINCT`,
so it just gets canonicalized as `DISTINCT`.
[docs]: https://dev.mysql.com/doc/refman/8.4/en/select.html
a437a32 to
a2459ae
Compare
iffyio
approved these changes
Feb 5, 2026
This file contains hidden or 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
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.
Adds support for MySQL-specific
SELECTmodifiers that appear after theSELECTkeyword. Grammar from the docs:Manual testing shows that these options can appear in any order relative to each other, so for the sake of fidelity, we parse this separately from how we parse distinct and other options for other dialects, in a new
Parser::parse_select_modifiersmethod.DISTINCTROWis a legacy (but not deprecated) synonym forDISTINCT, so it just gets canonicalized asDISTINCT.