Skip to content

Support the MySQL spatial types, SRID attribute, SPATIAL constraint, and CHAR/VARCHAR attributes - #42

Merged
kyleconroy merged 2 commits into
mainfrom
claude/missing-syntax-types-8qbqfh
Aug 19, 2026
Merged

Support the MySQL spatial types, SRID attribute, SPATIAL constraint, and CHAR/VARCHAR attributes#42
kyleconroy merged 2 commits into
mainfrom
claude/missing-syntax-types-8qbqfh

Conversation

@kyleconroy

Copy link
Copy Markdown
Contributor

Closes the remaining data-type gaps found by auditing the MySQL 26.7 reference manual's data-type chapter (§13) against parseType. All of this syntax postdates the goyacc grammar (TiDB never supported spatial data), so the grammar is written from the reference manual, following the precedent of the statement-coverage PRs (#38#41).

Spatial types (§13.4.1)

  • The eight spatial column data types: GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION, with GEOMCOLLECTION lexing as its GEOMETRYCOLLECTION synonym via the aliases table (the DECDECIMAL precedent).
  • MySQL reports every spatial column as type byte 0xff on the wire, so the subtypes get parser-only type bytes 0xe20xe8 following the TypeTiDBVectorFloat32 precedent; spatial FieldTypes carry the binary charset, like JSON. This keeps POINT round-tripping as POINT instead of collapsing to GEOMETRY.
  • The SRID n column attribute (§13.1.20.10): new ColumnOptionSrid, with the value in a new ColumnOption.UintValue field.
  • The SPATIAL [INDEX | KEY] table constraint (§15.1.20) in CREATE TABLE and ALTER TABLE ... ADD, mirroring the FULLTEXT alternative with a new ConstraintSpatial (CREATE SPATIAL INDEX already parsed).
  • CAST/CONVERT to the spatial types (§14.10, castable since MySQL 8.0.24), with RestoreAsCastType coverage.

CHAR/VARCHAR attributes (§13.3.1)

The audit found no missing type names beyond spatial, but three missing attribute spellings: CHAR(5) BYTE (the documented alias for BINARY(5)), VARCHAR(10) ASCII, and VARCHAR(10) UNICODE. The goyacc grammar allowed the ASCII/UNICODE/BYTE attributes only on TEXT/ENUM/SET/LONG; MySQL gives CHAR and VARCHAR the same attribute set. parseCharTail/parseVarcharTail now parse OptCharsetWithOptBinary — a superset whose default alternative is OptBinary, so every previously accepted spelling parses identically — and normalize the binary charset to BinaryFlag plus the binary collation, mirroring the TextType action, so CHAR(5) BYTE produces the same FieldType as parsing its BINARY(5) restore output.

UNICODE keeps the historical goyacc semantics: it maps to the unsupported ucs2 charset and fails with the same Unknown character set: 'ucs2' action error TEXT UNICODE has always produced; the goldens record that error contract.

Bookkeeping

  • Keyword tables: GEOMETRY, GEOMETRYCOLLECTION, LINESTRING, MULTILINESTRING, MULTIPOINT, MULTIPOLYGON, POLYGON, and SRID become unreserved keywords, matching their MySQL 26.7 classification (POINT already was); TestKeywordsLength counts updated accordingly.
  • The ast and types changes are backwards-compatible: appended enum values, a new ColumnOption field, and new type-byte map entries. testdata/errors.json is unaffected.
  • New spatial_types file-driven test group covers the types, SRID, the constraint forms, casts, and the new keywords in identifier position; compat_types gains the CHAR/VARCHAR attribute cases.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C3dMfdpMyaWffPoh8RBia4


Generated by Claude Code

claude added 2 commits August 18, 2026 23:11
…nstraint

Implement the spatial pieces of the MySQL type system, which postdate
the goyacc grammar (TiDB never supported spatial data):

- The spatial column data types (MySQL 26.7 §13.4.1): GEOMETRY, POINT,
  LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and
  GEOMETRYCOLLECTION, with GEOMCOLLECTION lexing as its
  GEOMETRYCOLLECTION synonym via the aliases table (the DEC → DECIMAL
  precedent). MySQL reports every spatial column as type byte 0xff on
  the wire, so the subtypes get parser-only type bytes 0xe2–0xe8
  following the TypeTiDBVectorFloat32 precedent; spatial FieldTypes
  carry the binary charset, like JSON.
- The SRID column attribute (§13.1.20.10): new ColumnOptionSrid with
  the value in a new ColumnOption.UintValue field.
- The SPATIAL [INDEX | KEY] table constraint (§15.1.20) in CREATE TABLE
  and ALTER TABLE ... ADD, mirroring the FULLTEXT alternative with a
  new ConstraintSpatial that restores canonically as SPATIAL; CREATE
  SPATIAL INDEX already parsed.
- CAST/CONVERT to the spatial types (§14.10, castable since MySQL
  8.0.24), with RestoreAsCastType coverage.

The ast and types changes are backwards-compatible: appended enum
values, a new ColumnOption field, and new type-byte map entries.

Keyword tables: GEOMETRY, GEOMETRYCOLLECTION, LINESTRING,
MULTILINESTRING, MULTIPOINT, MULTIPOLYGON, POLYGON, and SRID become
unreserved keywords, matching their MySQL 26.7 classification (POINT
already was); TestKeywordsLength counts updated accordingly.
testdata/errors.json is unaffected.

The new file-driven test group spatial_types covers the types, SRID,
the constraint forms, casts, and the new keywords in identifier
position.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C3dMfdpMyaWffPoh8RBia4
Auditing the MySQL 26.7 data-type chapter (§13) against parseType found
no missing type names after the spatial commit, but three missing
attribute spellings from §13.3.1: CHAR(5) BYTE (the documented alias
for BINARY(5)), VARCHAR(10) ASCII, and VARCHAR(10) UNICODE. The goyacc
grammar allowed the ASCII/UNICODE/BYTE attributes only on TEXT, ENUM,
SET, and LONG (OptCharsetWithOptBinary); MySQL's grammar gives CHAR and
VARCHAR the same attribute set.

parseCharTail and parseVarcharTail now parse OptCharsetWithOptBinary
instead of OptBinary — a superset whose default alternative is
OptBinary, so every previously accepted spelling parses identically —
and normalize the binary charset (spelled BYTE or CHARACTER SET binary)
to BinaryFlag plus the binary collation, mirroring the TextType action,
so CHAR(5) BYTE produces the same FieldType as parsing its BINARY(5)
restore output.

UNICODE keeps the historical goyacc semantics: the attribute maps to
the ucs2 charset, which is not supported, so it fails with the same
"Unknown character set: 'ucs2'" action error TEXT UNICODE has always
produced; the new compat_types goldens record that error contract.
testdata/errors.json is unaffected.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C3dMfdpMyaWffPoh8RBia4
@kyleconroy
kyleconroy merged commit ae648ff into main Aug 19, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants