I've started working on this and I'm somewhat stuck at the moment with the following grammar extension issue:

I've redefined GRANT grant_role TO .... to
GRANT role_list TO ...
This leads to 7 reduce/reduce conflicts, because:

We define

• object_privilege_list as:

  object_privilege_list:

  object_privilege

  | object_privilege_list ',' object_privilege

• role_list as:

  role_list:

  grant_role

  | role_list ',' grant_role

Within these two rules we allow for keywords such as EVENT, EXECUTE, FILE, PROCESS, RELOAD, SHUTDOWN.

Technically, the two grant statements should be unambigous:

GRANT EVENT, EXECUTE ON .....

GRANT EVENT, EXECUTE TO .....

These 2 statements are different. The first one refers to object privileges, while the other one refers to role grants. Bison finds these to be ambiguous because it needs to make a decision on which rule (object_privilege_list or role_list) to use, when it encounters the ',' (comma) token.
The decision would be clear, if the parser would look for the TO or ON keyword, but the lookahead token only looks forward one step.

Possible solutions:
Do not allow EVENT, EXECUTE, FILE, etc. as role names. (It will break people's existing databases on update).
Redefine both rules to account for this overlap. The downside to this approach is that it requires a pretty big amount of changes.

I wouldn't like the first solution. The second is straightforward, but requires a notable amount of changes. Like, create one rule that accepts a list of identifiers or privileges. Create a structure that can accumulate that list and at the end — when you see ON or TO — decide how to parse it. There are details, like having a column list forces the structure to be interpreted as a list of privileges, etc. One would need to remember positions in the list for every word t be able to do correct error messages. All in all not while not complex, but still a big change.

Taking into account that this is a minor task, I'd postpone it.

I agree that the first option is rather undesirable. I thought that there might be a simpler implementation but I guess there isn't one. I'll keep it as a back burner.