Skip to content

Conversation

@mvzink
Copy link
Contributor

@mvzink mvzink commented Jan 7, 2026

MySQL has a special case in CAST parsing where the type can be followed by ARRAY. This is only used for creating multi-valued indexes in InnoDB, so is only allowed in CREATE TABLE and other DDL statements when specifying keys. See the docs.

Given those restrictions, we could be significantly more restrictive in parsing this, e.g. not parsing ARRAY unless we are in a key specification. Or, if there was such a thing as a suffix array type definition, we could parse it as a type. But as far as I know, that doesn't exist in any supported SQL dialects, and encountering ARRAY here is unambiguous. So it seemed simplest to be permissive and always parse it. The only downside I can see is we are now adding a field to Expr::Cast.

MySQL has a special case in `CAST` parsing where the type can be
followed by `ARRAY`. This is only used for creating multi-valued indexes
in InnoDB, so is only allowed in `CREATE TABLE` and other DDL statements
when specifying keys. See the [docs].

Given those restrictions, we could be significantly more restrictive in
parsing this, e.g. not parsing `ARRAY` unless we are in a key
specification. Or, if there was such a thing as a suffix array type
definition, we could parse it as a type. But as far as I know, that
doesn't exist in any supported SQL dialects, and encountering `ARRAY`
here is unambiguous. So it seemed simplest to be permissive and always
parse it. The only downside I can see is we are now adding a field to
`Expr::Cast`. 

[docs]: https://dev.mysql.com/doc/refman/8.4/en/cast-functions.html#function_cast
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant