Parse SIGNED INTEGER type in MySQL CAST #1739
Conversation
mvzink
force-pushed
the
push-vlqruupookvx
branch
from
9616c36 to
b84315a
Compare
See relevant sqlparser [PR]. [PR]: apache/datafusion-sqlparser-rs#1739 Change-Id: I11a01b48f1649c6530cdbe7bd23c158e9fe4f888
mvzink
force-pushed
the
push-vlqruupookvx
branch
from
b84315a to
2877163
Compare
mvzink
changed the title
src/ast/data_type.rs
Outdated
| /// Semantically equivalent to `BIGINT`. | ||
| /// | ||
| /// [MySQL CAST]: https://dev.mysql.com/doc/refman/8.4/en/cast-functions.html | ||
| Signed(bool), |
There was a problem hiding this comment.
thinking it feels a unexpected to use Signed(true) to represent SIGNED INTEGER? and the repr assumes a mysql-only type which might not be the case going forward. Feels like it'd be clear to represent them explicitly as SIGNED and SIGNED INTEGER where both can be reused by other dialects later if needed?
There was a problem hiding this comment.
I'm not sure exactly what you mean. Different variants Signed = SIGNED and SignedInteger = SIGNED INTEGER? The only reason I didn't do that is there's already UnsignedInt = INT[EGER] UNSIGNED and it would be even more confusing to have UnsignedInteger = UNSIGNED INTEGER, and very disruptive to change the existing UnsignedInt to IntUnsigned or something.
There was a problem hiding this comment.
Ah I see, that is what you are suggesting. I misread your previous comment, sorry! I'll try that out.
There was a problem hiding this comment.
Fixed. Let me know if this is what you had in mind. Definitely could be a bit disruptive to downstream users.
MySQL doesn't have the same set of possible CAST types as for e.g. column definitions. For example, it raises a syntax error for `CAST(1 AS INTEGER SIGNED)` and instead expects `CAST(1 AS SIGNED INTEGER)`. We retain the current somewhat permissive datatype parsing behavior (e.g. allowing `CAST(1 AS BIGINT)` even though MySQL would raise a syntax error), and add datatypes for this specific case (`SIGNED [INTEGER]` and `UNSIGNED [INTEGER]`). To keep the naming consistent across datatypes, we also rename `UnsignedInt` to `IntUnsigned` and similar for other unsigned datatypes. This means they display in the same way they are written, i.e. `IntUnsigned = INT UNSIGNED` instead of `UnsignedInt = INT UNSIGNED`. Closes apache#1589
mvzink
force-pushed
the
push-vlqruupookvx
branch
from
2877163 to
3f70716
Compare
mvzink
changed the title
MySQL doesn't have the same set of possible CAST types as for e.g. column definitions. For example, it raises a syntax error for
CAST(1 AS INTEGER SIGNED)and instead expectsCAST(1 AS SIGNED INTEGER).We retain the current somewhat permissive datatype parsing behavior (e.g. allowing
CAST(1 AS BIGINT)even though MySQL would raise a syntax error), and add datatypes for this specific case (SIGNED [INTEGER]andUNSIGNED [INTEGER]).To keep the naming consistent across datatypes, we also rename
UnsignedInttoIntUnsignedand similar for other unsigned datatypes. This means they display in the same way they are written, i.e.IntUnsigned = INT UNSIGNEDinstead ofUnsignedInt = INT UNSIGNED.Closes #1589