Skip to content

[BUG] 5.4-SNAPSHOT: MySQL numeric column modifiers are inconsistently modeled #2532

Description

@minleejae

Failing SQL feature

MySQL numeric column modifiers SIGNED, UNSIGNED, and ZEROFILL are parsed inconsistently by ColDataType.

SQL examples

CREATE TABLE t (
    a INT UNSIGNED,
    b INT(11) UNSIGNED ZEROFILL,
    c DECIMAL(10, 2) SIGNED NOT NULL
);

The same inconsistency is visible when parsing type fragments directly:

INT UNSIGNED
INT(11) UNSIGNED
DECIMAL(10, 2) UNSIGNED
INT UNSIGNED ZEROFILL

Actual behavior

Tested with JSqlParser 5.4-SNAPSHOT at 8397d3a225e3fb380151044add1e4509d01955bf:

  • INT UNSIGNED is returned as the data type name INT UNSIGNED.
  • After type arguments, UNSIGNED is left outside ColDataType.
  • ZEROFILL is also left outside ColDataType.
  • A complete CREATE TABLE can parse only because these tokens fall through to ColumnDefinition.columnSpecs.

As a result, callers cannot inspect or rewrite these modifiers consistently.

Expected behavior

ColDataType should expose structured signedness and zerofill properties, parse the modifiers consistently with or without type arguments, and deparse without losing tokens. Existing casts such as CAST(value AS UNSIGNED) must remain supported.

Software information

AI assistance

OpenAI Codex was used to identify and test the inconsistent parser paths. The reproductions and proposed behavior were manually reviewed against the MySQL documentation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions