[xmaks82]

Ref #167

A table level check constraint broke parsing of the whole CREATE TABLE, with any context (MySQL 8.0.16+ and MariaDB 10.2.1+ both print it in SHOW CREATE TABLE):

CREATE TABLE t (a INT, b INT, CONSTRAINT `chk_ab` CHECK (a < b), c INT)

Before:

A symbol name was expected! A reserved keyword can not be used as a column name without backquotes. (near "CHECK")
Unexpected beginning of statement. (near "a")
Unexpected beginning of statement. (near "b")
Unexpected beginning of statement. (near "c")
Unrecognized statement type. (near "INT")

and build() gave CREATE TABLE t (`a` int, `b` int): the constraint and column c were lost. The same happens for an unnamed CHECK (a > 0) and for CONSTRAINT CHECK (...).

Now CreateDefinition accepts [CONSTRAINT [symbol]] CHECK (expr) and stores it like a column check: name is the constraint symbol (or null), isConstraint is set for CONSTRAINT, and the expression is in options (the existing CHECK field option, so [NOT] ENFORCED works too). Utils\Table::getFields() skips it because it has no type.

Column level CHECK and ALTER TABLE ... ADD CONSTRAINT ... CHECK are not changed.

Docs:

• https://mariadb.com/docs/server/reference/sql-statements/data-definition/constraint
• https://dev.mysql.com/doc/refman/8.0/en/create-table-check-constraints.html

Tests: parser fixture parseCreateTableCheckConstraint (named, unnamed, CONSTRAINT CHECK, NOT ENFORCED, the example from #167, a column after the constraints) and a round-trip test in tests/Builder/CreateStatementTest.php.