matrixorigin / matrixorigin/matrixone

[Bug]: SQL parser error for USE statement when MULTI_STATEMENTS capability is negotiated

Open
#24,149 0 comments 0 reactions 1 assignee Claimed by @daviszhen View on GitHub
ai-medium kind/bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.