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.
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
Missing data type aliases #355
Comments
Working on a MR to fix this. |
xsist10
added a commit
to xsist10/PHP-SQL-Parser
that referenced
this issue
Dec 2, 2023
In an attempt to fix the character set issue introduced by me in greenlion#355 This change separates out the CHARACTER check to do a look ahead to see if the next keyword is SET and splits the logic appropriately. An alternative would be to look back at the constructed expression array ($expr) to see if a ExpressionType::DATA_TYPE has already been defined. This is an alternative fix to the fix proposed by greenlion#366
greenlion
pushed a commit
that referenced
this issue
Dec 18, 2023
* Confusion between CHARACTER type and CHARACTER SET In an attempt to fix the character set issue introduced by me in #355 This change separates out the CHARACTER check to do a look ahead to see if the next keyword is SET and splits the logic appropriately. An alternative would be to look back at the constructed expression array ($expr) to see if a ExpressionType::DATA_TYPE has already been defined. This is an alternative fix to the fix proposed by #366 * Updated removed PHPUnit expect function. * Added additional tests for explicit conditions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
MySQL has a lot of badly documented aliases for data types.
Example:
But ColumnDefinitionProcessor.php only supports a subset of them.
Parsing a
CREATE TABLE
query using one of these aliases results in the specific column being skipped and a warning message:The text was updated successfully, but these errors were encountered: