MySQL: `CREATE INDEx`: allow `USING` clause before `ON` #2029

MohamedAbdeen21 · 2025-09-15T21:19:39Z

MySQL allows specifying the index type USING index_type before the ON clause in CREATE INDEX statements.

This PR allows the CREATE INDEX parser to accept both positions of the USING clause, regardless of the dialect.

docs: https://dev.mysql.com/doc/refman/8.4/en/create-index.html

MohamedAbdeen21 · 2025-09-15T21:20:25Z

src/parser/mod.rs

        let concurrently = self.parse_keyword(Keyword::CONCURRENTLY);
        let if_not_exists = self.parse_keywords(&[Keyword::IF, Keyword::NOT, Keyword::EXISTS]);
+
+        let mut using = None;


Not a fan of this mut but also not a fan of returning a tuple of (index_name, using) at line 7067.

Seems okay IMO.

src/parser/mod.rs

mvzink · 2025-09-15T21:32:46Z

src/parser/mod.rs

        let concurrently = self.parse_keyword(Keyword::CONCURRENTLY);
        let if_not_exists = self.parse_keywords(&[Keyword::IF, Keyword::NOT, Keyword::EXISTS]);
+
+        let mut using = None;


Seems okay IMO.

mvzink

Great, thanks!

iffyio · 2025-09-19T07:59:12Z

src/parser/mod.rs

-            None
-        };
+
+        using = self.parse_optional_using_then_index_type()?.or(using);


Should this be something like

using = using.or_else(|| self.parse_optional_using_then_index_type()).transpose()?;

in that we should only look to parse again if we didn't parse a value already?

As Michael pointed out earlier, MySQL does allow having two "USING" clauses. In that case, the second one overwrites the first.

Might be worth a comment on this line, because at first glance (or if you haven't tried it on MySQL yourself) it does seem backwards 😛

Ah I see, double checking do the tests include the scenario where two USING clauses are specified? If not we can probably add those

Good point. Added a second test with two USING clauses. Force-pushed to resolve conflicts and squashed the commits.

MySQL allows specifying the index type `USING index_type` before the `ON` clause in `CREATE INDEX` statements. This PR allows the `CREATE INDEX` parser to accept both positions of the `USING` clause, regardless of the dialect. docs: https://dev.mysql.com/doc/refman/8.4/en/create-index.html

iffyio · 2025-09-24T13:06:19Z

tests/sqlparser_common.rs

+    // Can't use `verified_stmt` here as the USING will be placed after the `ON` clause
+    match all_dialects().parse_sql_statements(sql).unwrap()[0].clone() {


for the tests, I think we can use one_statement_parses_to() instead so that the test covers the display impl as well?
Also can we merge both test functions into the same parse_create_index_using() or similar function - since they cover the same feature

Updated tests and one other small change for the third position of USING.

MohamedAbdeen21 · 2025-09-24T20:53:09Z

src/parser/mod.rs

+        {
+            using = None;
+        };
+


USING can be used in 3 different positions across the other dialects. This makes sure that only the latest USING is recognized.

iffyio · 2025-09-25T14:16:09Z

tests/sqlparser_common.rs

+    let sql = "CREATE INDEX idx_name USING BTREE ON table_name (col1) USING HASH";
+    let expected = "CREATE INDEX idx_name ON table_name(col1) USING HASH";


I'm not sure I followed the intent, why do we drop the first clause vs keeping both as in the input?

We can, but it's just super confusing because there is the USING field and another IndexOption::IndexType in the index_options field.

The point here is to mimic mysql behaviour of only keeping the second, not preserve the input.

hmm what's confusing do you mean with the first clause going into the using field and the second clause going into the index_options field?
It feels like it'd be unusual for the parser to swallow some of its input, and in general we avoid mimicking server behavior in the parser, so its currently unclear to me what the rationale is

I guess we can keep both then, but it will be confusing for users having two index types.

And while I don't like how we have two separate fields for that, I really don't want to hold this PR any longer

MohamedAbdeen21 commented Sep 15, 2025

View reviewed changes

mvzink suggested changes Sep 15, 2025

View reviewed changes

mvzink approved these changes Sep 15, 2025

View reviewed changes

iffyio reviewed Sep 19, 2025

View reviewed changes

iffyio changed the title ~~MySQL: allow USING clause before ON in CREATE INDEX~~ MySQL: CREATE INDEx: allow USING clause before ON Sep 19, 2025

MohamedAbdeen21 force-pushed the main branch from cad1ec4 to bcc9f7a Compare September 23, 2025 22:15

MohamedAbdeen21 force-pushed the main branch from bcc9f7a to c6a3910 Compare September 23, 2025 22:17

iffyio reviewed Sep 24, 2025

View reviewed changes

merge test cases for USING in CREATE INDEX

43a114c

MohamedAbdeen21 commented Sep 24, 2025

View reviewed changes

add comment explaining USING behaviour

bdbd173

iffyio reviewed Sep 25, 2025

View reviewed changes

allow multiple index types in parsed result

2713ea4

		// Can't use `verified_stmt` here as the USING will be placed after the `ON` clause
		match all_dialects().parse_sql_statements(sql).unwrap()[0].clone() {

		let sql = "CREATE INDEX idx_name USING BTREE ON table_name (col1) USING HASH";
		let expected = "CREATE INDEX idx_name ON table_name(col1) USING HASH";

MySQL: CREATE INDEx: allow USING clause before ON #2029

Are you sure you want to change the base?

MySQL: CREATE INDEx: allow USING clause before ON #2029

Uh oh!

Conversation

MohamedAbdeen21 commented Sep 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mvzink left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MySQL: `CREATE INDEx`: allow `USING` clause before `ON` #2029

MySQL: `CREATE INDEx`: allow `USING` clause before `ON` #2029