Fix MySQL parsing of GRANT, REVOKE, and CREATE VIEW #1538
Conversation
This is needed for parsing MySQL-style `'user'@'host'` grantee syntax. As far as I can tell, no dialect allows quotes or backticks as part of an identifier (regardless of whether it starts with `@`) without other specific syntax (e.g. nested in another quote style and thus not starting with `@`), so this shouldn't adversely affect non-MySQL dialects.
Introduces a new `Grantee` enum to differentiate bare identifiers (every other database: `root`) from user/host pairs (MySQL: `'root'@'%'`). While we're here, make the CASCADE/RESTRICT syntax for REVOKE optional since Postgres doesn't require it and MySQL doesn't allow it. Add support for MySQL wildcard object syntax: `GRANT ALL ON *.* ...`
|
Would appreciate feedback on the naming the MySQL-specific params types (would a generic/non-branded name be better?) and the API change for wildcard support (didn't want to change all 107 |
| @@ -8353,20 +8409,40 @@ impl<'a> Parser<'a> { | |||
| } | |||
| } | |||
|
|
|||
| /// Parse a possibly qualified, possibly quoted identifier, optionally allowing for wildcards, | |||
| /// e.g. *, `foo`.*, or "foo"."bar" | |||
| pub fn parse_object_name_with_wildcards( | |||
There was a problem hiding this comment.
The method sounds like what parse_wildcard_expr does, minus the return type. Can we reuse that functionality instead? e.g. if we move that logic out to its own method so that parse_wildcard_expr and other functionality like grant etc can call it directly?
There was a problem hiding this comment.
Still having a think about the best way to do this; posting the other updates for further feedback.
There was a problem hiding this comment.
Sorry it's taken me a while to get to this. It's a bit tricky, partly because the expression form shouldn't accept *.*. I will try to come back to this later, but have had higher priorities the last few weeks and probably will until later in January. In my opinion, it might be better to avoid dragging on with more merge conflicts etc. and merge without this suggested refactor. Let me know your thoughts.
Though as far as I know they are entirely MySQL specific.
…mething unexpected
'user'@'host'syntax.*.*.CASCADE/RESTRICTin revoke statements optional since MySQL doesn't accept it.user@hostsyntax), and security context.