GeezerVison

What

SELECT 0xFF FROM t (any 0x-hex literal followed by whitespace/a keyword) failed to parse, while SELECT 0xFF,1 FROM t parsed fine. This makes the 0x hex literal form stop greedily consuming trailing whitespace.

Why

MySQL and other dialects accept 0x-prefixed hex literals as values/select items (#2435). Today such a literal followed by FROM or a keyword fails:

SELECT 0xFF FROM t
  -> ParseException: Encountered: <S_IDENTIFIER> / "t", at line 1, column 18

while the same literal followed by a comma parses fine — a confusing inconsistency.

Root cause

HEX_VALUE was defined as ["0"-"9","A"-"F", " "] and shared by both hex literal forms in S_HEX:

<S_HEX: ("X" ("'" ( <HEX_VALUE> )* "'" (" ")*)+ | "0x" ( <HEX_VALUE> )+ )>

The space is intentional for the X'..' form, which allows internal whitespace (e.g. X'01 bc 2a', exercised by StringValueTest#testParseInput_BYTEA). But for the 0x form, <HEX_VALUE>+ then greedily matched the trailing space and any following hex letter — so 0xFF FROM was tokenised as a single S_HEX (0xFF F), leaving ROM t, and the parser choked on t at column 18.

How

Split the shared token so each form gets the character class it needs:

• X'..' keeps HEX_VALUE (with space — preserves X'01 bc 2a').
• 0x.. uses a new HEX_DIGIT token (["0"-"9","A"-"F"], no space).

IGNORE_CASE = true already makes both forms match upper/lower case, so 0xff works too. HexValue itself is unchanged.

Testing

• New HexValueTest#testHexLiteralFollowedByPrimaryKeyword: SELECT 0xFF FROM t, SELECT 0xff FROM t, SELECT 0xDEADBEEF FROM t, SELECT 0xab FROM dual — all parse to a HexValue select item.
• Full suite: mvn test → 4647 tests, 0 failures, 0 errors (26 pre-existing skipped), including the X'01 bc 2a' regression in StringValueTest and existing InsertTest#testHexValues*.
• checkstyle:check / pmd:check / license:check-file-header clean.

Fixes #2435