GRANT statement with "resource_option" fails to be parsed

[ckolbitsch-work]

Parsing a GRANT statement fails if that statement contains "resource_option" as described here:

https://dev.mysql.com/doc/refman/5.6/en/grant.html

1. What did you do?

We run a fork of ghostferry (a SQL replication tool) and parse incoming replication statements. The following statement fails to be parsed although MySQL (5.6 and later) accept it as valid statement:

parser := sqlParser: parser.New()
sql := "GRANT USAGE ON *.* TO 'myuser'@'%'  WITH MAX_USER_CONNECTIONS 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_QUERIES_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0"
stmts, _, err := parser.Parse(sql, "", "")

the err value is set to non-nil

2. What did you expect to see?

The same (or similar) output as when passing this string:

GRANT USAGE ON *.* TO 'myuser'@'%'

That is, err should be nil and a valid list of statements is returned

3. What did you see instead?

err is non-nil with this output:

line 1 column 90 near \"MAX_CONNECTIONS_PER_HOUR 0 MAX_QUERIES_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0\"

4. What version of TiDB SQL Parser are you using?

commit 635dd473fca2587243f1d6012e73290cfce95851 (HEAD -> master, origin/master, origin/HEAD)
Author: bb7133 <[email protected]>
Date:   Mon Feb 24 15:39:21 2020 +0800

[ckolbitsch-work]

FYI: same issue occurs with CREATE PROCEDURE statements, including the one given as example in the mysql docs:

https://dev.mysql.com/doc/refman/5.6/en/create-procedure.html

CREATE PROCEDURE test1(IN country CHAR(3), OUT cities INT)
BEGIN
    SELECT COUNT(*) INTO cities FROM world.city WHERE CountryCode = country;
END

parser error:

DBG: line 1 column 16 near "PROCEDURE test1(IN country CHAR(3), OUT cities INT) BEGIN SELECT COUNT(*) INTO cities FROM world.city WHERE CountryCode = country; END"  []

Would probably be a separate "bug" (actually just a missing feature in the parser), but wanted to post it here for reference

[bb7133]

Would probably be a separate "bug" (actually just a missing feature in the parser), but wanted to post it here for reference

Thanks for reporting this, since TiDB does not support stored procedure, we may not add this to the parser for now.