Rainmemery commented on issue #40295: URL: https://github.com/apache/shardingsphere/issues/40295#issuecomment-6336445148
I'd like to work on this one — I'll send a PR within 3 days. Root cause, in case it helps the review: the MySQL `expr` rule lists the `expr orOperator expr` alternative **before** `expr XOR expr`. ANTLR4 resolves the alternatives of a directly left-recursive rule by their order, with the earlier alternative binding tighter, so the grammar currently ranks `OR` above `XOR`: ``` | expr andOperator expr | expr orOperator expr <- binds tighter than XOR | expr XOR expr ``` MySQL's table is `AND` > `XOR` > `OR`, so swapping the two alternatives is enough; `AND` keeps its position above both, and `1 OR 1 AND 1` / `1 AND 1 OR 1` are already correct today. Locally confirmed against `master` (27591ff6): | SQL | before | after | | --- | --- | --- | | `1 OR 1 XOR 1` | `(1 OR 1) XOR 1` | `1 OR (1 XOR 1)` | | `1 XOR 1 OR 1` | `1 XOR (1 OR 1)` | `(1 XOR 1) OR 1` | | `1 OR 1 AND 1` | `1 OR (1 AND 1)` | `1 OR (1 AND 1)` (unchanged) | | `1 AND 1 OR 1` | `(1 AND 1) OR 1` | `(1 AND 1) OR 1` (unchanged) | No visitor change is needed: `MySQLStatementVisitor#visitExpr` discriminates on `ctx.XOR()` / `ctx.andOperator()` / `ctx.orOperator()`, which are mutually exclusive. I'll cover it with a Parser IT case rather than a unit test, per the testing rules. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
