GeezerVison

Summary

A named table-level CHECK constraint in a CREATE TABLE statement failed to parse:

CONSTRAINT chk_next_sequence CHECK (NextSequence >= 1)

The parser reported "A symbol name was expected! A reserved keyword can not be used as a column name without backquotes" at CHECK and dropped the constraint (and everything after it) from the parsed statement. This is phpmyadmin/phpmyadmin#20572; the bug lives here because phpMyAdmin delegates parsing to this library. Unnamed table-level CHECK constraints were rejected the same way.

Changes

• CreateDefinitions state 1 now recognises the CHECK keyword and parses [CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED] with the existing field options, the same way a column-level CHECK is parsed in state 3.
• Definitions that carry options but neither a data type nor a key (exactly the CHECK constraint shape) are no longer dropped when the definition list is flushed.
• New parser test data parseCreateTableWithCheckConstraint using the statement from the original report, registered in CreateStatementTest.

Verified locally: the reported statement now parses with no errors and builds back with both constraints; the full test suite passes (1025 tests, 4120 assertions).

Fixes phpmyadmin/phpmyadmin#20572