@drzl/analyzer 1.14.0 → 1.15.0

package/README.md

@@ -47,6 +47,17 @@ The CLI consumes this analysis to generate validation, services, and routers.
 - relations (incl. inferred), enums
 - issues (warnings/errors) for constraints and shape
 
+Per column, beyond the type: `nullable`, `hasDefault`, `defaultValue` (literal defaults only),
+`isGenerated`, `enumValues`, `maxLength` (characters), `maxBytes` (MySQL's TEXT family is a byte
+budget, which is a different measurement on the same kind of column), `min`/`max`,
+`arrayDimensions`, `format`, and `shape` for values that are not scalars (json, buffer, tuple,
+vector, bitstring, customType).
+
+`DRZL_ANL_UNKNOWN_COLUMN` is reported for any column whose validator would accept anything, which
+is the shape a missing type mapping takes: nothing throws, and every row passes.
+
 ## Notes
 
-- Best‑effort introspection aligned with Drizzle symbols across versions.
+- Best‑effort introspection aligned with Drizzle symbols across versions. Both live majors are
+  covered and diffed against each other in CI: 0.4x and v1 model arrays and enums differently, and
+  reading only one silently typed every `.array()` column as `unknown` on the other.

package/dist/index.cjs

@@ -57,11 +57,16 @@ var MYSQL_TEXT_CAPS = {
   mediumblob: 16777215,
   longblob: 4294967295
 };
-var V1_FLOAT_BOUNDS = {
-  float: ["-8388608", "8388607"],
-  // real / float4, 2^23
-  double: ["-140737488355328", "140737488355327"]
-  // double precision / float8, 2^47
+var FLOAT32_MAX = "340282346638528859811704183484516925440";
+var PG_FLOAT4_INPUT_MAX = "340282356779733661637539395458142568448";
+var PG_FLOAT4_RANGE = [`-${PG_FLOAT4_INPUT_MAX}`, PG_FLOAT4_INPUT_MAX];
+var MYSQL_FLOAT_RANGE = [`-${FLOAT32_MAX}`, FLOAT32_MAX];
+var JS_SAFE_INTEGER_BOUNDS = ["-9007199254740991", "9007199254740991"];
+var TUPLE_CLASS_SHAPES = {
+  // `line()` is the trap here: its `drizzle:entityKind` is `PgLine` while its constructor is
+  // `PgLineTuple`, and this path matches on the constructor.
+  PgPointTuple: { kind: "tuple", length: 2 },
+  PgLineTuple: { kind: "tuple", length: 3 }
 };
 function describeV1Column(column) {
   const codec = column?.codec;
@@ -111,7 +116,8 @@ function describeV1Column(column) {
       break;
     case "float":
     case "double": {
-      [out.min, out.max] = V1_FLOAT_BOUNDS[semantic];
+      if (semantic === "float")
+        [out.min, out.max] = codec === "float4" ? PG_FLOAT4_RANGE : MYSQL_FLOAT_RANGE;
       out.integer = false;
       out.tsType = "number";
       out.dbType = semantic === "float" ? "REAL" : "DOUBLE";
@@ -200,7 +206,7 @@ function describeV1Column(column) {
         out.tsType = "number";
         out.dbType = "NUMERIC";
         out.integer = false;
-        [out.min, out.max] = ["-9007199254740991", "9007199254740991"];
+        [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
       } else if (js === "string") {
         out.tsType = "string";
         out.dbType = codec === "varchar" ? "VARCHAR" : codec === "char" ? "CHAR" : "TEXT";
@@ -507,6 +513,11 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       [out.min, out.max] = range;
       out.integer = true;
     }
+    if (Object.prototype.hasOwnProperty.call(_SchemaAnalyzer.INEXACT_RANGES, ctor)) {
+      const inexact = _SchemaAnalyzer.INEXACT_RANGES[ctor];
+      if (inexact) [out.min, out.max] = inexact;
+      out.integer = false;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -578,9 +589,25 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "Date", dbType: "TIMESTAMP" };
       case "PgNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
-      case "PgFloat":
       case "PgDoublePrecision":
         return { tsType: "number", dbType: "DOUBLE" };
+      // `real()` builds a `PgReal`, which matched no arm and fell through to the coarse
+      // `/Numeric|Float|Double|Real/i` below, so a real column was labelled NUMERIC while v1
+      // called it REAL. The arm above used to name `PgFloat` alongside `PgDoublePrecision`, and
+      // no such class exists in pg-core on either major: `float` is MySQL's spelling and Gel's
+      // is `GelReal`, both of which are matched elsewhere. Enumerated from the module's own
+      // exports on 0.45.2 and on 1.0.0-rc.4, which name only PgReal and PgDoublePrecision.
+      case "PgReal":
+        return { tsType: "number", dbType: "REAL" };
+      // 0.4x names a point and a line by their mode. `point()` is a `PgPointTuple` and `line()` a
+      // `PgLineTuple`, whose entity kind is `PgLine` while its constructor is not, and both used
+      // to fall through to `/Point|Line/i` and come back `string`. The driver hands back [x, y]
+      // and [a, b, c], so a select schema built on 0.4x refused every row, and an insert schema
+      // took the one string form `mapToDriverValue` turns into something Postgres rejects.
+      case "PgPointTuple":
+        return { tsType: "[number, number]", dbType: "POINT" };
+      case "PgLineTuple":
+        return { tsType: "[number, number, number]", dbType: "LINE" };
       case "PgJson":
       case "PgJsonb":
         return { tsType: "any", dbType: ctor === "PgJsonb" ? "JSONB" : "JSON" };
@@ -703,8 +730,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
       const sqlType = sqlKind.startsWith("MySql") && typeof col?.getSQLType === "function" ? String(col.getSQLType()).toLowerCase() : void 0;
       const byteCap = sqlType ? MYSQL_TEXT_CAPS[sqlType] : void 0;
-      const jsonShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : void 0;
-      const shape = (v1?.shape ?? jsonShape)?.kind;
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : TUPLE_CLASS_SHAPES[String(col?.constructor?.name ?? "")];
+      const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
       const wide = (finalTs === "unknown" || finalTs === "any") && (!shape || shape === "custom");
       if (wide) {
@@ -733,7 +760,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         // that spread has nothing to say and this is the only source.
         ...arrayDims ? { arrayDimensions: arrayDims } : {},
         // Only where v1 did not already describe the value, so a shaped column keeps its shape.
-        ...jsonShape && !v1?.shape ? { shape: jsonShape } : {},
+        ...fallbackShape && !v1?.shape ? { shape: fallbackShape } : {},
         ...byteCap && v1?.maxBytes === void 0 ? { maxBytes: byteCap } : {}
       });
     }
@@ -1011,6 +1038,60 @@ _SchemaAnalyzer.INT_RANGES = {
   MySqlBigInt64: ["-9223372036854775808", "9223372036854775807"],
   SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"]
 };
+/**
+ * The numeric column classes that are not exact, and the magnitude each one can really hold.
+ *
+ * Only drizzle v1 states this outright, as a `float` or `double` semantic on `dataType`. On
+ * 0.4x the same columns reach the analyzer by class name, `INT_RANGES` was the only range table
+ * on that path, and so nothing said anything about them at all: not the range, and not that
+ * they are inexact. The parity gate measured seven of the ten classes below and reported DRZL
+ * differing from the first-party validator for the same major on all seven. The three
+ * SingleStore classes are in no fixture either pass carries and are covered by unit tests alone.
+ *
+ * Differing is what the gate reports, not what it forbids. Most of its waivers have DRZL
+ * accepting something official refuses and the run counts them; an earlier version of this
+ * sentence said the gate exists to forbid being looser, which the same commit's own success
+ * banner denies.
+ *
+ * `null` is a value in this table and is not the same as a class it does not name. It says the
+ * column is inexact and that no finite magnitude bound is truthful for it, which is the case for
+ * every 8 byte float: float8 is the JavaScript number's own format, so Postgres accepts every
+ * finite JS number into one, measured to `Number.MAX_VALUE`. Read with an own-property test for
+ * that reason, and because a plain object answers to `constructor` and `toString`.
+ *
+ * `integer: false` travels with every entry, bound or not, and what it decides depends on which.
+ * `isIntegerColumn` falls back to "declares both bounds" when the flag is absent, so on a bounded
+ * entry the flag is the only thing stopping the emitted schema calling `.int()` and refusing 1.5.
+ * On an unbounded one it decides nothing, measured both ways against the real function in
+ * `@drzl/validation-core`'s integer-column.spec.ts. It is stated there because it is true of the
+ * column, not because it guards anything. That spec is where the measurement moved when the
+ * analyzer's copy of it turned out to be a closed loop; this sentence went on naming
+ * floats-and-tuples-0.4x.spec.ts, which asserts the flag is present and nothing about what it
+ * decides.
+ *
+ * The widths are the type's, not the name's: MySQL and SingleStore `real` is a synonym for
+ * `double` unless REAL_AS_FLOAT is set, and SQLite `real` is an 8 byte IEEE float. Both are
+ * `number double` on drizzle v1, which is where these pairings come from.
+ */
+_SchemaAnalyzer.INEXACT_RANGES = {
+  // 4 byte floats, the one width a database refuses a magnitude for, and the two that have one
+  // refuse at different values. SingleStore is MySQL wire-compatible and unmeasured here, so it
+  // takes MySQL's rather than the wider of the two.
+  PgReal: PG_FLOAT4_RANGE,
+  MySqlFloat: MYSQL_FLOAT_RANGE,
+  SingleStoreFloat: MYSQL_FLOAT_RANGE,
+  // 8 byte floats, which hold every finite JS number
+  PgDoublePrecision: null,
+  MySqlDouble: null,
+  MySqlReal: null,
+  SQLiteReal: null,
+  SingleStoreDouble: null,
+  SingleStoreReal: null,
+  // `numeric({ mode: 'number' })`, which v1 reaches through the bare-number arm of
+  // `describeV1Column`. This one is about what a JS number can carry rather than about the
+  // column, which Postgres caps far lower: it refuses 2147483648 into a `numeric(10,2)`.
+  PgNumericNumber: JS_SAFE_INTEGER_BOUNDS
+};
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;
 // Annotate the CommonJS export names for ESM import in node:

package/dist/index.d.cts

@@ -354,6 +354,42 @@ declare class SchemaAnalyzer {
      * promise a precision that cannot survive the round trip.
      */
     private static readonly INT_RANGES;
+    /**
+     * The numeric column classes that are not exact, and the magnitude each one can really hold.
+     *
+     * Only drizzle v1 states this outright, as a `float` or `double` semantic on `dataType`. On
+     * 0.4x the same columns reach the analyzer by class name, `INT_RANGES` was the only range table
+     * on that path, and so nothing said anything about them at all: not the range, and not that
+     * they are inexact. The parity gate measured seven of the ten classes below and reported DRZL
+     * differing from the first-party validator for the same major on all seven. The three
+     * SingleStore classes are in no fixture either pass carries and are covered by unit tests alone.
+     *
+     * Differing is what the gate reports, not what it forbids. Most of its waivers have DRZL
+     * accepting something official refuses and the run counts them; an earlier version of this
+     * sentence said the gate exists to forbid being looser, which the same commit's own success
+     * banner denies.
+     *
+     * `null` is a value in this table and is not the same as a class it does not name. It says the
+     * column is inexact and that no finite magnitude bound is truthful for it, which is the case for
+     * every 8 byte float: float8 is the JavaScript number's own format, so Postgres accepts every
+     * finite JS number into one, measured to `Number.MAX_VALUE`. Read with an own-property test for
+     * that reason, and because a plain object answers to `constructor` and `toString`.
+     *
+     * `integer: false` travels with every entry, bound or not, and what it decides depends on which.
+     * `isIntegerColumn` falls back to "declares both bounds" when the flag is absent, so on a bounded
+     * entry the flag is the only thing stopping the emitted schema calling `.int()` and refusing 1.5.
+     * On an unbounded one it decides nothing, measured both ways against the real function in
+     * `@drzl/validation-core`'s integer-column.spec.ts. It is stated there because it is true of the
+     * column, not because it guards anything. That spec is where the measurement moved when the
+     * analyzer's copy of it turned out to be a closed loop; this sentence went on naming
+     * floats-and-tuples-0.4x.spec.ts, which asserts the flag is present and nothing about what it
+     * decides.
+     *
+     * The widths are the type's, not the name's: MySQL and SingleStore `real` is a synonym for
+     * `double` unless REAL_AS_FLOAT is set, and SQLite `real` is an 8 byte IEEE float. Both are
+     * `number double` on drizzle v1, which is where these pairings come from.
+     */
+    private static readonly INEXACT_RANGES;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.d.ts

@@ -354,6 +354,42 @@ declare class SchemaAnalyzer {
      * promise a precision that cannot survive the round trip.
      */
     private static readonly INT_RANGES;
+    /**
+     * The numeric column classes that are not exact, and the magnitude each one can really hold.
+     *
+     * Only drizzle v1 states this outright, as a `float` or `double` semantic on `dataType`. On
+     * 0.4x the same columns reach the analyzer by class name, `INT_RANGES` was the only range table
+     * on that path, and so nothing said anything about them at all: not the range, and not that
+     * they are inexact. The parity gate measured seven of the ten classes below and reported DRZL
+     * differing from the first-party validator for the same major on all seven. The three
+     * SingleStore classes are in no fixture either pass carries and are covered by unit tests alone.
+     *
+     * Differing is what the gate reports, not what it forbids. Most of its waivers have DRZL
+     * accepting something official refuses and the run counts them; an earlier version of this
+     * sentence said the gate exists to forbid being looser, which the same commit's own success
+     * banner denies.
+     *
+     * `null` is a value in this table and is not the same as a class it does not name. It says the
+     * column is inexact and that no finite magnitude bound is truthful for it, which is the case for
+     * every 8 byte float: float8 is the JavaScript number's own format, so Postgres accepts every
+     * finite JS number into one, measured to `Number.MAX_VALUE`. Read with an own-property test for
+     * that reason, and because a plain object answers to `constructor` and `toString`.
+     *
+     * `integer: false` travels with every entry, bound or not, and what it decides depends on which.
+     * `isIntegerColumn` falls back to "declares both bounds" when the flag is absent, so on a bounded
+     * entry the flag is the only thing stopping the emitted schema calling `.int()` and refusing 1.5.
+     * On an unbounded one it decides nothing, measured both ways against the real function in
+     * `@drzl/validation-core`'s integer-column.spec.ts. It is stated there because it is true of the
+     * column, not because it guards anything. That spec is where the measurement moved when the
+     * analyzer's copy of it turned out to be a closed loop; this sentence went on naming
+     * floats-and-tuples-0.4x.spec.ts, which asserts the flag is present and nothing about what it
+     * decides.
+     *
+     * The widths are the type's, not the name's: MySQL and SingleStore `real` is a synonym for
+     * `double` unless REAL_AS_FLOAT is set, and SQLite `real` is an 8 byte IEEE float. Both are
+     * `number double` on drizzle v1, which is where these pairings come from.
+     */
+    private static readonly INEXACT_RANGES;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.js

@@ -17,11 +17,16 @@ var MYSQL_TEXT_CAPS = {
   mediumblob: 16777215,
   longblob: 4294967295
 };
-var V1_FLOAT_BOUNDS = {
-  float: ["-8388608", "8388607"],
-  // real / float4, 2^23
-  double: ["-140737488355328", "140737488355327"]
-  // double precision / float8, 2^47
+var FLOAT32_MAX = "340282346638528859811704183484516925440";
+var PG_FLOAT4_INPUT_MAX = "340282356779733661637539395458142568448";
+var PG_FLOAT4_RANGE = [`-${PG_FLOAT4_INPUT_MAX}`, PG_FLOAT4_INPUT_MAX];
+var MYSQL_FLOAT_RANGE = [`-${FLOAT32_MAX}`, FLOAT32_MAX];
+var JS_SAFE_INTEGER_BOUNDS = ["-9007199254740991", "9007199254740991"];
+var TUPLE_CLASS_SHAPES = {
+  // `line()` is the trap here: its `drizzle:entityKind` is `PgLine` while its constructor is
+  // `PgLineTuple`, and this path matches on the constructor.
+  PgPointTuple: { kind: "tuple", length: 2 },
+  PgLineTuple: { kind: "tuple", length: 3 }
 };
 function describeV1Column(column) {
   const codec = column?.codec;
@@ -71,7 +76,8 @@ function describeV1Column(column) {
       break;
     case "float":
     case "double": {
-      [out.min, out.max] = V1_FLOAT_BOUNDS[semantic];
+      if (semantic === "float")
+        [out.min, out.max] = codec === "float4" ? PG_FLOAT4_RANGE : MYSQL_FLOAT_RANGE;
       out.integer = false;
       out.tsType = "number";
       out.dbType = semantic === "float" ? "REAL" : "DOUBLE";
@@ -160,7 +166,7 @@ function describeV1Column(column) {
         out.tsType = "number";
         out.dbType = "NUMERIC";
         out.integer = false;
-        [out.min, out.max] = ["-9007199254740991", "9007199254740991"];
+        [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
       } else if (js === "string") {
         out.tsType = "string";
         out.dbType = codec === "varchar" ? "VARCHAR" : codec === "char" ? "CHAR" : "TEXT";
@@ -467,6 +473,11 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       [out.min, out.max] = range;
       out.integer = true;
     }
+    if (Object.prototype.hasOwnProperty.call(_SchemaAnalyzer.INEXACT_RANGES, ctor)) {
+      const inexact = _SchemaAnalyzer.INEXACT_RANGES[ctor];
+      if (inexact) [out.min, out.max] = inexact;
+      out.integer = false;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -538,9 +549,25 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         return { tsType: "Date", dbType: "TIMESTAMP" };
       case "PgNumeric":
         return { tsType: "string", dbType: "NUMERIC" };
-      case "PgFloat":
       case "PgDoublePrecision":
         return { tsType: "number", dbType: "DOUBLE" };
+      // `real()` builds a `PgReal`, which matched no arm and fell through to the coarse
+      // `/Numeric|Float|Double|Real/i` below, so a real column was labelled NUMERIC while v1
+      // called it REAL. The arm above used to name `PgFloat` alongside `PgDoublePrecision`, and
+      // no such class exists in pg-core on either major: `float` is MySQL's spelling and Gel's
+      // is `GelReal`, both of which are matched elsewhere. Enumerated from the module's own
+      // exports on 0.45.2 and on 1.0.0-rc.4, which name only PgReal and PgDoublePrecision.
+      case "PgReal":
+        return { tsType: "number", dbType: "REAL" };
+      // 0.4x names a point and a line by their mode. `point()` is a `PgPointTuple` and `line()` a
+      // `PgLineTuple`, whose entity kind is `PgLine` while its constructor is not, and both used
+      // to fall through to `/Point|Line/i` and come back `string`. The driver hands back [x, y]
+      // and [a, b, c], so a select schema built on 0.4x refused every row, and an insert schema
+      // took the one string form `mapToDriverValue` turns into something Postgres rejects.
+      case "PgPointTuple":
+        return { tsType: "[number, number]", dbType: "POINT" };
+      case "PgLineTuple":
+        return { tsType: "[number, number, number]", dbType: "LINE" };
       case "PgJson":
       case "PgJsonb":
         return { tsType: "any", dbType: ctor === "PgJsonb" ? "JSONB" : "JSON" };
@@ -663,8 +690,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
       const sqlType = sqlKind.startsWith("MySql") && typeof col?.getSQLType === "function" ? String(col.getSQLType()).toLowerCase() : void 0;
       const byteCap = sqlType ? MYSQL_TEXT_CAPS[sqlType] : void 0;
-      const jsonShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : void 0;
-      const shape = (v1?.shape ?? jsonShape)?.kind;
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : TUPLE_CLASS_SHAPES[String(col?.constructor?.name ?? "")];
+      const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
       const wide = (finalTs === "unknown" || finalTs === "any") && (!shape || shape === "custom");
       if (wide) {
@@ -693,7 +720,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         // that spread has nothing to say and this is the only source.
         ...arrayDims ? { arrayDimensions: arrayDims } : {},
         // Only where v1 did not already describe the value, so a shaped column keeps its shape.
-        ...jsonShape && !v1?.shape ? { shape: jsonShape } : {},
+        ...fallbackShape && !v1?.shape ? { shape: fallbackShape } : {},
         ...byteCap && v1?.maxBytes === void 0 ? { maxBytes: byteCap } : {}
       });
     }
@@ -971,6 +998,60 @@ _SchemaAnalyzer.INT_RANGES = {
   MySqlBigInt64: ["-9223372036854775808", "9223372036854775807"],
   SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"]
 };
+/**
+ * The numeric column classes that are not exact, and the magnitude each one can really hold.
+ *
+ * Only drizzle v1 states this outright, as a `float` or `double` semantic on `dataType`. On
+ * 0.4x the same columns reach the analyzer by class name, `INT_RANGES` was the only range table
+ * on that path, and so nothing said anything about them at all: not the range, and not that
+ * they are inexact. The parity gate measured seven of the ten classes below and reported DRZL
+ * differing from the first-party validator for the same major on all seven. The three
+ * SingleStore classes are in no fixture either pass carries and are covered by unit tests alone.
+ *
+ * Differing is what the gate reports, not what it forbids. Most of its waivers have DRZL
+ * accepting something official refuses and the run counts them; an earlier version of this
+ * sentence said the gate exists to forbid being looser, which the same commit's own success
+ * banner denies.
+ *
+ * `null` is a value in this table and is not the same as a class it does not name. It says the
+ * column is inexact and that no finite magnitude bound is truthful for it, which is the case for
+ * every 8 byte float: float8 is the JavaScript number's own format, so Postgres accepts every
+ * finite JS number into one, measured to `Number.MAX_VALUE`. Read with an own-property test for
+ * that reason, and because a plain object answers to `constructor` and `toString`.
+ *
+ * `integer: false` travels with every entry, bound or not, and what it decides depends on which.
+ * `isIntegerColumn` falls back to "declares both bounds" when the flag is absent, so on a bounded
+ * entry the flag is the only thing stopping the emitted schema calling `.int()` and refusing 1.5.
+ * On an unbounded one it decides nothing, measured both ways against the real function in
+ * `@drzl/validation-core`'s integer-column.spec.ts. It is stated there because it is true of the
+ * column, not because it guards anything. That spec is where the measurement moved when the
+ * analyzer's copy of it turned out to be a closed loop; this sentence went on naming
+ * floats-and-tuples-0.4x.spec.ts, which asserts the flag is present and nothing about what it
+ * decides.
+ *
+ * The widths are the type's, not the name's: MySQL and SingleStore `real` is a synonym for
+ * `double` unless REAL_AS_FLOAT is set, and SQLite `real` is an 8 byte IEEE float. Both are
+ * `number double` on drizzle v1, which is where these pairings come from.
+ */
+_SchemaAnalyzer.INEXACT_RANGES = {
+  // 4 byte floats, the one width a database refuses a magnitude for, and the two that have one
+  // refuse at different values. SingleStore is MySQL wire-compatible and unmeasured here, so it
+  // takes MySQL's rather than the wider of the two.
+  PgReal: PG_FLOAT4_RANGE,
+  MySqlFloat: MYSQL_FLOAT_RANGE,
+  SingleStoreFloat: MYSQL_FLOAT_RANGE,
+  // 8 byte floats, which hold every finite JS number
+  PgDoublePrecision: null,
+  MySqlDouble: null,
+  MySqlReal: null,
+  SQLiteReal: null,
+  SingleStoreDouble: null,
+  SingleStoreReal: null,
+  // `numeric({ mode: 'number' })`, which v1 reaches through the bare-number arm of
+  // `describeV1Column`. This one is about what a JS number can carry rather than about the
+  // column, which Postgres caps far lower: it refuses 2147483648 into a `numeric(10,2)`.
+  PgNumericNumber: JS_SAFE_INTEGER_BOUNDS
+};
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;
 export {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@drzl/analyzer",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "private": false,
   "license": "Apache-2.0",
   "type": "module",
@@ -43,7 +43,7 @@
     "url": "https://github.com/sponsors/omar-dulaimi"
   },
   "scripts": {
-    "build": "tsup src/index.ts --dts --format esm,cjs",
+    "build": "tsup src/index.ts --dts --format esm,cjs --clean",
     "lint": "eslint . --ext .ts",
     "test": "vitest run --testTimeout=20000"
   }