RF06 unquotes MySQL/MariaDB 'user'@'host' specifications, producing SQL that no longer parses

Search before asking

• I searched the issues and found no similar issue. The open/closed RF06 issues are about case sensitivity, reserved keywords, TSQL special characters and RF04 conflicts — none about user specifications.

What Happened

sqlfluff fix turns valid MySQL/MariaDB into SQL that sqlfluff itself cannot parse. RF06 unquotes both halves of a 'user'@'host' specification, but that is not an identifier pair — the quoting is part of the syntax.

-- in
CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';
-- after `sqlfluff fix --dialect mysql`
CREATE USER jeffrey@localhost IDENTIFIED BY 'password';   -- no longer parses

L:   1 | P:  23 | RF06 | Unnecessary quoted identifier 'localhost'.

Verified with parse status measured before and after the fix, so this is corruption rather than a pre-existing parse gap:

Same result on --dialect mariadb.

Not part of this report: ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'new'; does not parse before the fix either. That looks like a separate dialect gap, and I have deliberately kept it out of this issue rather than inflate it.

Affected fixtures already in the repo

The repository's own corpus reproduces this — these four fixtures parse clean and stop parsing after fix:

• test/fixtures/dialects/mysql/create_user.sql
• test/fixtures/dialects/mysql/grant.sql
• test/fixtures/dialects/mariadb/create_user.sql
• test/fixtures/dialects/mariadb/grant.sql

Expected Behaviour

fix should never produce SQL that does not parse. RF06 should not apply inside a user specification, in the same way it already declines other contexts where quoting is semantic.

Observed Behaviour

RF06 treats 'jeffrey' and 'localhost' as quoted identifiers and strips both. In MySQL these are the account name and host parts of an account specification; unquoted they are not equivalent, and in general are not even valid.

How to reproduce

echo "CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';" > repro.sql
sqlfluff parse --dialect mysql repro.sql   # clean
sqlfluff fix   --dialect mysql -f repro.sql
sqlfluff parse --dialect mysql repro.sql   # unparsable

Dialect

MySQL and MariaDB.

Version

4.3.0, from a checkout of main.

Configuration

Default. No .sqlfluff — RF06 is in the default rule set, so this is out-of-the-box behaviour.

Are you willing to work on and submit a PR to address the issue?

Yes.

How this was found. I ran a round-trip check over the whole fixture corpus — for every fixture that parses cleanly, assert that fix output still parses. That surfaced 8 corruptions across 2,249 fixtures; these four are one root cause. The same method found #8415. If it is useful I am happy to write the remaining ones up separately rather than bundling unrelated bugs here.

AI disclosure (per CONTRIBUTING): I used an AI coding agent to run the corpus scan and draft this report. What I verified myself is the before/after parse status of every statement in the table above, through the CLI with default configuration, and the separation of the ALTER USER case as a distinct pre-existing gap rather than part of this bug.