feat(parser): add DOUBLE PRECISION as a synonym for DOUBLE (float64) - #25109
Merged
Conversation
DOUBLE PRECISION is the SQL-standard name for a 64-bit float. Add it as a synonym for DOUBLE: same internal type (FloatFamily, width 64, MYSQL_TYPE_DOUBLE -> T_float64), and it normalizes to `double` in the catalog like MySQL (`double`, `double(M,D)`). - New PRECISION token; "precision" keyword now maps to it. PRECISION is reserved (matching MySQL, where it is a reserved word) — this is required to keep `DOUBLE` alone valid while also accepting `DOUBLE PRECISION` without a grammar conflict, and the keyword-policy test allows it because PRECISION is MySQL-reserved. - decimal_type gains `DOUBLE PRECISION float_length_opt`, so the type works everywhere the type grammar is used: column DDL, CAST, CONVERT and the :: operator. Parser regenerated via goyacc (0 conflicts). BVT: test/distributed/cases/dtype/double_precision.sql covers DDL (incl. DOUBLE PRECISION(M,D)), CAST / CONVERT / :: targets, and float64 arithmetic. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
…ision # Conflicts: # pkg/sql/parsers/dialect/mysql/mysql_sql.go
Add to double_precision.sql, per review: - M/D validation errors: (300) width, (10,40) scale, (5,10) M<D. - Reserved-keyword negatives: `precision` as a column name and as an alias now error (PRECISION is reserved), documenting the behavior change. - Composition with UNSIGNED / ZEROFILL and NOT NULL / DEFAULT / PRIMARY KEY. - ALTER TABLE ADD / MODIFY COLUMN with DOUBLE PRECISION. - Float64 proof: cast(0.1)+cast(0.2)=0.30000000000000004 IEEE-754 artifact, and the double magnitude range (max/min) round-trips. 43/43 pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
Review — test coverage & error casesI reviewed the source ( Implementation: correct and robust. The original test was happy-path only. The error/edge cases below were untested; I've now added them (commit
BVT Minor (not changed):
Also merged latest upstream |
heni02
approved these changes
Jun 24, 2026
iamlinjunhong
approved these changes
Jun 25, 2026
Contributor
|
Queued — the merge queue status continues in this comment ↓. |
Contributor
Merge Queue Status
Waiting for any of
All conditions
|
Contributor
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the SQL-standard
DOUBLE PRECISIONtype as a synonym forDOUBLE(64-bit float).Behaviour
DOUBLE PRECISIONmaps to the same internal type asDOUBLE—FloatFamily, width 64,MYSQL_TYPE_DOUBLE→T_float64— and normalizes todoublein the catalog, matching MySQL:It works everywhere the type grammar is used — column DDL,
CAST,CONVERT, and the::operator:Implementation
PRECISIONtoken; theprecisionkeyword now maps to it.decimal_typegains aDOUBLE PRECISION float_length_optproduction (same action asDOUBLE, normalized todouble).mysql_sql.gois the generated diff.Note on reserving
PRECISIONPRECISIONis now a reserved keyword. Keeping it non-reserved introduces a shift/reduce conflict: afterDOUBLE, the empty-float_length_optreduce competes with thePRECISIONshift because a non-reserved keyword lands in FOLLOW sets, andDOUBLEalone must stay a valid type. ReservingPRECISIONresolves this cleanly and matches MySQL (wherePRECISIONis a reserved word), soTestNewKeywordsHaveExplicitIdentifierPolicyaccepts it without a legacy exception. No existing BVT case usesprecisionas an identifier.Testing
test/distributed/cases/dtype/double_precision.sql— DDL (incl.DOUBLE PRECISION(M,D)),CAST/CONVERT/::targets, and float64 arithmetic.pkg/sql/parsers/...unit tests pass (incl. the keyword-policy test).expression,pg_cast,dml/insertBVT suites all 100%.🤖 Generated with Claude Code