Add support for DECIMAL(M, D) columns in MySQL EET - #1352
Merged
Conversation
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
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.
Summary
The EET oracle's type inference previously required
FLOAT/DOUBLE/DECIMALcolumns to be created without an(M, D)precision/scale specifier, because its type-pinningCAST(used for the redundant branch of transformation rules No. 3–4) could only target the bare types.This PR removes the exclusion for
DECIMALby tracking a column's exact(M, D)end-to-end and reproducing it asCAST(... AS DECIMAL(M, D)).FLOAT/DOUBLEremain excluded under EET. This is becauseFLOAT(M, D)/DOUBLE(M, D)is not a validCASTtarget, so there is no way to reproduce such a column's exact type in a type-pinning cast (also noteFLOAT(M, D)/DOUBLE(M, D)columns are deprecated anyway, but they still remain supported for all other oracles).Changes
Schema — track scale (
MySQLSchema.java)scalefield (+getScale()) toMySQLColumn, read frominformation_schema.columns.NUMERIC_SCALE, alongside the already-readNUMERIC_PRECISION.MySQLColumnconstructor and its single call site now threadscalethrough.information_schemaalways reports a concrete(M, D)for aDECIMALcolumn, defaulting to(10, 0)when the column was declared without one.Type domain — enrich
CastType(MySQLCastOperation.java)MySQLCastOperation.CastTypewas changed from a plainenuminto a small final value class. Its keyword kinds (SIGNED,UNSIGNED,CHAR,FLOAT,DOUBLE,DECIMAL) remainpublic static finalsingletons (so existing e.g.== CastType.SIGNEDcomparisons are unaffected), whileCastType.decimal(m, d)producesDECIMALinstances carrying(M, D).getPrecision/getScale,equals/hashCode(over kind +(M, D)), and atoStringthat rendersDECIMAL(M, D).Transformer (
MySQLEETTransformer.java)inferColumnTypemaps aDECIMALcolumn toCastType.decimal(column.getPrecision(), column.getScale()).commonTypecompares with.equals()instead of==, so twoDECIMALsubexpressions with matching(M, D)(distinct instances) share a type. If(M, D)differs,commonTypeconservatively returnsnull, as MySQL's precise aggregation rule in this case is not known.Table generation (
MySQLTableGenerator.java)DECIMALhas now been reverted to the original behaviour of callingoptionallyAddPrecisionAndScale(i.e.(M, D)is now allowed under EET).FLOAT/DOUBLEroute through a newoptionallyAddFloatingPointPrecisionAndScale, which omits(M, D)only while EET is active.