Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Backport to release-14: Fix parsing of CAST() statements #10512 and #10514 #10517

Merged
merged 2 commits into from
Jun 16, 2022
Merged

Backport to release-14: Fix parsing of CAST() statements #10512 and #10514 #10517

merged 2 commits into from
Jun 16, 2022

Commits on Jun 16, 2022

  1. Fix parsing of CAST() statements (vitessio#10512) 

    * Fix parsing of CAST() statements

CAST() was treated as an alias for CONVERT() but with slightly different
syntax.

This is also described in the documentation at
https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html,
specifically:

With CAST(expr AS type syntax, the CAST() function takes an expression of
any type and produces a result value of the specified type. This operation
may also be expressed as CONVERT(expr, type), which is equivalent. If expr
is NULL, CAST() returns NULL.

This is wrong sadly. CAST() is not equivalent to CONVERT(), specifically
in the context of a CREATE TABLE. For JSON keys, the ARRAY attribute is
possible on a CAST(), but that is not accepted for a CONVERT().

The difference in parsing also shows in MySQL:

```
mysql> select convert(json_keys(c), char(64) array) from t;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'array) from t' at line 1
mysql> select cast(json_keys(c) as char(64) array) from t;
ERROR 1235 (42000): This version of MySQL doesn't yet support 'Use of CAST( .. AS .. ARRAY) outside of functional index in CREATE(non-SELECT)/ALTER TABLE or in general expressions'
```

Here the first statement can't be parsed at all. The second is properly
parsed, but ARRAY is not allowed in the context of CAST() in this
situation (and only in a CREATE TABLE).

This means we should really treat these as two separate expressions and
don't store them both in the same structure. The change here creates a
separate CAST structure, removes the ARRAY option from CONVERT and
updates the grammar and all tests accordingly.

Signed-off-by: Dirkjan Bussink <[email protected]>

* Handle new cast expression in evalengine and planbuilder

Signed-off-by: Dirkjan Bussink <[email protected]>

* evalengine: do not duplicate CAST/CONVERT translation

Signed-off-by: Vicent Marti <[email protected]>

Co-authored-by: Vicent Marti <[email protected]>
Signed-off-by: Manan Gupta <[email protected]>
    @dbussink @vmg @GuptaManan100
    2 people authored and GuptaManan100 committed Jun 16, 2022
    Configuration menu
    Copy the full SHA
    bdeceb5 View commit details
    Browse the repository at this point in the history

  2. Add back unary single column expression check (vitessio#10514) 

    This was accidentally removed in
vitessio#10512 but it shouldn't have
been.

Signed-off-by: Dirkjan Bussink <[email protected]>
    @dbussink @GuptaManan100
    dbussink authored and GuptaManan100 committed Jun 16, 2022
    Configuration menu
    Copy the full SHA
    ae65d6e View commit details
    Browse the repository at this point in the history