GeezerVison

What

Allow an optional UNIQUE prefix on INDEX inside CREATE TABLE, so MySQL-style UNIQUE INDEX name (cols) ... parses and round-trips.

Why

MySQL accepts UNIQUE INDEX name (cols) ... as an inline table constraint (it is produced by tooling and appears in real schemas). JSQLParser currently rejects it:

net.sf.jsqlparser.JSQLParserException: Encountered unexpected token: "UNIQUE" "UNIQUE"

Only INDEX name (...) and [UNIQUE] KEY name (...) were accepted; the UNIQUE INDEX combination fell through every CreateTableConstraint alternative.

How

The INDEX branch of CreateTableConstraint now accepts an optional leading UNIQUE, and the index type is rendered as UNIQUE INDEX when present (mirroring the existing [UNIQUE] KEY branch). LOOKAHEAD(3) becomes LOOKAHEAD(4) to cover the extra token. The branches remain unambiguous: UNIQUE INDEX name ( matches this branch, UNIQUE KEY name ( still matches the [UNIQUE] ... KEY branch, and UNIQUE ( still matches the [CONSTRAINT] UNIQUE branch.

Testing

• New CreateTableTest#testUniqueIndexIssue1893 — UNIQUE INDEX idx (a, b) USING BTREE COMMENT '...' round-trips (fails before the grammar change), and a plain INDEX idx (a) still parses.
• ./gradlew test --tests net.sf.jsqlparser.statement.create.CreateTableTest — green.
• Full ./gradlew test — no regressions introduced by this change. The 33 unrelated failures observed locally are pre-existing environmental issues (Mockito inline MockMaker does not initialise under the local JDK 17 / Windows toolchain, and ParserKeywordsUtilsTest resolves its temp file to C:\WINDOWS); both reproduce on unmodified master.

Fixes #1893