matrixorigin / matrixorigin/matrixone
[Bug]: SQL parser error for USE statement when MULTI_STATEMENTS capability is negotiated
- Dominant language
- Go
- Stars
- 1.9k
- Forks
- 311
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 768
Description
## Is there an existing issue for the same bug?
- [x] I have checked the existing issues.
## Branch Name
main
## Commit ID
v3.0.9 (latest Docker image `matrixorigin/matrixone:latest`, digest `sha256:839150a2e6784270d0c14f0b488684c9c177721c7ea95ddeaec31ddaf485ab67`)
## Actual Behavior
When a MySQL client connects with the `CLIENT_MULTI_STATEMENTS` capability flag set (bit 16), executing a `USE `db_name`` statement via COM_QUERY fails with a SQL parser error:
```
error returned from database: 1064 (HY000): SQL parser error: You have an error in your SQL syntax;
check the manual that corresponds to your MatrixOne server version for the right syntax to use.
syntax error at line 1 column 32 near " USE `mem_u_37a8eec1ce19687d`";
```
This is triggered by sqlx (Rust MySQL driver) which always negotiates `MULTI_STATEMENTS` during the handshake. The `USE` statement itself is sent as a normal single COM_QUERY packet — no actual multi-statement batching occurs.
## Expected Behavior
`USE `db_name`` should succeed regardless of whether `CLIENT_MULTI_STATEMENTS` was negotiated during the handshake, consistent with standard MySQL behavior.
## Steps to Reproduce
1. Connect to MatrixOne v3.0.9 with a client that sets `CLIENT_MULTI_STATEMENTS` in the capability flags during handshake (e.g. sqlx Rust driver, which always sets this flag)
2. Execute: `USE `mem_u_37a8eec1ce19687d`` via COM_QUERY
3. Observe SQL parser error 1064
Note: The same `USE` statement works correctly when connecting without `CLIENT_MULTI_STATEMENTS` (e.g. standard `mysql` CLI client).
## Additional information
- MatrixOne version: v3.0.9
- Driver: sqlx-mysql (Rust), which unconditionally sets `MULTI_STATEMENTS | MULTI_RESULTS | PS_MULTI_RESULTS` during capability negotiation
- Workaround: None available on the client side without patching the driver
- Secondary issue observed: `GREATEST()` function returns error `20105: not supported: function or operator 'greatest'`
Contributor guide
Assessment
This issue has not been assessed yet.