@drzl/analyzer 1.17.4 → 1.17.6

package/dist/index.cjs

@@ -87,6 +87,7 @@ var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
   "SingleStoreBinary",
   "SingleStoreVarBinary"
 ]);
+var BUFFER_CLASSES = /* @__PURE__ */ new Set(["SQLiteBlobBuffer"]);
 function describeV1Column(column) {
   const codec = column?.codec;
   const dataType = column?.dataType;
@@ -111,6 +112,14 @@ function describeV1Column(column) {
     case "int53":
     case "uint53":
     case "int64": {
+      if (DECIMAL_BIGINT_MODE.test(entityKind)) {
+        out.tsType = "bigint";
+        out.dbType = "NUMERIC";
+        out.integer = true;
+        const range2 = decimalModeRange(column, entityKind, "bigint");
+        if (range2) [out.min, out.max] = range2;
+        break;
+      }
       const range = {
         int8: ["-128", "127"],
         int16: ["-32768", "32767"],
@@ -253,10 +262,11 @@ function describeV1Column(column) {
         out.tsType = "number";
         out.dbType = "NUMERIC";
         out.integer = false;
-        [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
+        const range = decimalModeRange(column, entityKind, "number");
+        if (range) [out.min, out.max] = range;
         if (codec === "numeric:number") {
           out.allowsNaN = true;
-          out.allowsInfinity = false;
+          out.allowsInfinity = !declaredDecimalRange(column);
         }
       } else if (js === "string") {
         out.tsType = "string";
@@ -285,6 +295,28 @@ function declaredLength(column) {
   const n = column?.length ?? column?.config?.length ?? column?.config?.dimensions;
   return typeof n === "number" && Number.isFinite(n) && n > 0 ? n : void 0;
 }
+function declaredDecimalRange(column) {
+  const cfg = column?.config ?? {};
+  const precision = column?.precision ?? cfg.precision;
+  const scale = column?.scale ?? cfg.scale ?? 0;
+  if (typeof precision !== "number" || !Number.isInteger(precision) || precision < 1)
+    return void 0;
+  if (typeof scale !== "number" || !Number.isInteger(scale) || scale < 0) return void 0;
+  const nines = "9".repeat(precision);
+  const max = scale === 0 ? nines : scale < precision ? `${nines.slice(0, precision - scale)}.${nines.slice(precision - scale)}` : `0.${"0".repeat(scale - precision)}${nines}`;
+  return [`-${max}`, max];
+}
+var DECIMAL_NUMBER_MODE = /(?:Numeric|Decimal)Number$/;
+var DECIMAL_BIGINT_MODE = /(?:Numeric|Decimal)BigInt$/;
+var MYSQL_IMPLICIT_DECIMAL_RANGE = ["-9999999999", "9999999999"];
+function decimalModeRange(column, kind, mode) {
+  const declared = declaredDecimalRange(column);
+  if (declared) return declared;
+  if (kind.startsWith("MySql") || kind.startsWith("SingleStore"))
+    return MYSQL_IMPLICIT_DECIMAL_RANGE;
+  if (kind.startsWith("SQLite")) return void 0;
+  return mode === "number" ? JS_SAFE_INTEGER_BOUNDS : void 0;
+}
 var VIEW_CONFIG_FIELDS = {
   "drizzle:Columns": "selectedFields",
   "drizzle:Name": "name",
@@ -582,6 +614,19 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       out.allowsNaN = nonFinite.nan;
       out.allowsInfinity = nonFinite.infinity;
     }
+    if (DECIMAL_NUMBER_MODE.test(ctor)) {
+      const range2 = decimalModeRange(column, ctor, "number");
+      if (range2) [out.min, out.max] = range2;
+      out.integer = false;
+      if (ctor === "PgNumericNumber") {
+        out.allowsNaN = true;
+        out.allowsInfinity = !declaredDecimalRange(column);
+      }
+    } else if (DECIMAL_BIGINT_MODE.test(ctor)) {
+      const range2 = decimalModeRange(column, ctor, "bigint");
+      if (range2) [out.min, out.max] = range2;
+      out.integer = true;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -593,12 +638,36 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           tsType: column?.config?.mode === "timestamp" ? "Date" : "number",
           dbType: "INTEGER"
         };
+      // Both timestamp modes of `integer()`, which are one class and one type. `timestamp` and
+      // `timestamp_ms` differ in the scale of the number on the wire, seconds against
+      // milliseconds, and `mapFromDriverValue` consumes that difference and hands back a `Date`
+      // either way; nothing downstream of the analyzer ever sees the integer. So an arm keyed on
+      // the class covers both, where the mode check that used to answer this fell through the
+      // switch to a default arm testing `config.mode === 'timestamp'` and named only the first.
+      // The second came back `unknown`, and every generator emitted a schema accepting anything.
+      //
+      // `DATE` rather than the `INTEGER` that mode check returned, so the two majors describe the
+      // column identically. `dbType` is read in exactly one place outside this file,
+      // `isIntegerColumn`, which the generators consult only for a `tsType` of `number`, so the
+      // relabel reaches no output. Measured rather than argued: emitting a `Date` column under
+      // both labels, nullable and not, through all five generators gives ten byte-identical pairs.
+      case "SQLiteTimestamp":
+        return { tsType: "Date", dbType: "DATE" };
       case "SQLiteText":
         return { tsType: "string", dbType: "TEXT" };
       case "SQLiteReal":
         return { tsType: "number", dbType: "REAL" };
+      // No 0.4x column is a `SQLiteBlob`: `sqlite-core` builds a `SQLiteBlobBuffer`, a
+      // `SQLiteBlobJson` or a `SQLiteBigInt`, one per mode, and exports no class of this name at
+      // all. The arm answers the hand-built column in sqlite-types.spec.ts and nothing drizzle
+      // produces, which is why a real `blob()` reached neither it nor anything else.
       case "SQLiteBlob":
         return { tsType: "Uint8Array", dbType: "BLOB" };
+      // The class a real `blob()` and `blob({ mode: 'buffer' })` both build. See `BUFFER_CLASSES`
+      // for the measurement; the answers here are v1's own for the same column, so this is the
+      // two majors agreeing rather than a new opinion.
+      case "SQLiteBlobBuffer":
+        return { tsType: "Buffer", dbType: "BYTEA" };
       // SQLite spells a mode as a distinct class rather than as config, so `text({mode:'json'})`
       // is a `SQLiteTextJson` and matched no arm at all: the column came back UNKNOWN, which is
       // wider than the `any` a json column at least used to get.
@@ -825,7 +894,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         if (/^Gel/i.test(ctor)) {
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/Int53|Integer|SmallInt/i.test(ctor)) return { tsType: "number", dbType: "INTEGER" };
-          if (/Real|DoublePrecision/i.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+          if (/DoublePrecision/i.test(ctor)) return { tsType: "number", dbType: "DOUBLE" };
+          if (/Real/i.test(ctor)) return { tsType: "number", dbType: "REAL" };
           if (/Decimal/i.test(ctor)) return { tsType: "string", dbType: "NUMERIC" };
           if (/UUID/i.test(ctor)) return { tsType: "string", dbType: "UUID" };
           if (/Json/i.test(ctor)) return { tsType: "any", dbType: "JSON" };
@@ -876,11 +946,13 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const v1 = describeV1Column(col);
       const constraints = this.columnConstraints(col);
       if (v1?.shape) delete constraints.maxLength;
-      const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
+      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 ctorName = String(col?.constructor?.name ?? "");
-      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : NUMBER_VECTOR_CLASSES.has(ctorName) ? { kind: "numberVector", length: declaredLength(col) } : BIT_STRING_CLASSES.has(ctorName) ? { kind: "bitstring", length: declaredLength(col), exact: true } : GEOMETRIC_CLASS_SHAPES[ctorName];
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : BUFFER_CLASSES.has(ctorName) ? { kind: "buffer" } : NUMBER_VECTOR_CLASSES.has(ctorName) ? { kind: "numberVector", length: declaredLength(col) } : BIT_STRING_CLASSES.has(ctorName) ? { kind: "bitstring", length: declaredLength(col), exact: true } : GEOMETRIC_CLASS_SHAPES[ctorName];
       if (fallbackShape?.kind === "byteString") delete constraints.maxLength;
       const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
@@ -1243,11 +1315,29 @@ _SchemaAnalyzer.INEXACT_RANGES = {
   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
+  // Gel, whose `real` is a `std::float32` and whose `doublePrecision` is a `std::float64`. Both
+  // used to be answered by a `/Real|DoublePrecision/i` arm that said NUMERIC and stated nothing
+  // else at all, so a `real` column accepted 1e300 and the server refused it.
+  //
+  // Measured on a live Gel 7.1 (`geldata/gel:7`, sys::get_version_as_str() -> 7.1+08db576)
+  // through the `gel` client, casting each literal so the server parses it, and again through a
+  // stored property on a real object type. The float32 edge is Postgres's exactly, to the double:
+  //
+  //   3.4028234663852886e38   accepted, returned unchanged
+  //   3.4028235677973366e38   accepted, and stored as 3.4028234663852886e38
+  //   3.402823567797337e38    refused, "is out of range for type std::float32"
+  //   1e300                   refused, the same way
+  //
+  // The same value accepted, the same next double up refused, and the same rounding down of the
+  // midpoint, so it takes the constant already here rather than a second name for one number.
+  // float64 took 1e300 and Number.MAX_VALUE faithfully, for the reason no 8 byte float has a
+  // truthful finite bound.
+  GelReal: PG_FLOAT4_RANGE,
+  GelDoublePrecision: null
 };
+// `numeric`/`decimal` in either of its two numeric modes is deliberately not in the table above.
+// Its bound is not a fixed magnitude per class but the precision each column declares for itself,
+// which no table keyed on a class name can hold; see `declaredDecimalRange`.
 /**
  * The Postgres number columns that hold a non-finite double, and which of the three each holds.
  *
@@ -1258,17 +1348,25 @@ _SchemaAnalyzer.INEXACT_RANGES = {
  * table also answers for a v1 column and the two answers are identical rather than merely
  * compatible. non-finite-numbers.spec.ts asserts that agreement through the real analyzer.
  *
- * Postgres only. No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a
- * `float`/`double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while
- * silently turning `NaN` into NULL, which is a different answer that has to arrive whole.
+ * No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a `float`/
+ * `double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while silently
+ * turning `NaN` into NULL, which is a different answer that has to arrive whole.
+ *
+ * Gel does belong, and is the fourth and fifth entries. Measured on a live Gel 7.1 rather than
+ * inferred from it being Postgres-backed: both `std::float32` and `std::float64` stored `nan`,
+ * `inf` and `-inf` and handed all three back as `NaN`, `Infinity` and `-Infinity`, through a cast
+ * and again through a stored property. Without them every row of such a column failed validation.
  *
  * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
- * `Infinity`. `PgNumericNumber` states `infinity: false` on purpose; see `Column.allowsNaN`.
+ * `Infinity`. `PgNumericNumber` is absent because its answer is no longer flat: it takes `NaN` at
+ * any width and an infinity only where no precision is declared, which is a per-column question
+ * this table cannot ask. `columnConstraints` answers it beside the bound that decides it.
  */
 _SchemaAnalyzer.PG_NON_FINITE = {
   PgReal: { nan: true, infinity: true },
   PgDoublePrecision: { nan: true, infinity: true },
-  PgNumericNumber: { nan: true, infinity: false }
+  GelReal: { nan: true, infinity: true },
+  GelDoublePrecision: { nan: true, infinity: true }
 };
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;

package/dist/index.d.cts

@@ -48,8 +48,16 @@ interface Column {
      *
      * Strings rather than numbers because a 64 bit bound is not representable as a JS number:
      * `9223372036854775807` rounds to `9223372036854775808` the moment it becomes one, so a
-     * numeric field here would silently emit a wrong bound. Absent for floats and for `numeric`,
-     * which have no integer range.
+     * numeric field here would silently emit a wrong bound. A 20 digit `numeric(20,0)` bound is
+     * further past that again.
+     *
+     * Not an integer range, despite the name this field used to be described by. An inexact column
+     * carries one too: a `real` is bounded by the magnitude the database refuses past, and a
+     * `numeric(10,2)` by the width its own declaration states. `integer` says which kind it is, and
+     * saying it is what stops a bounded float schema refusing 1.5.
+     *
+     * Absent where nothing declares a bound: an 8 byte float holds every finite JS number, and a
+     * `numeric` with no precision holds arbitrary precision.
      */
     min?: string;
     max?: string;
@@ -76,14 +84,22 @@ interface Column {
      * does too, but a `numeric(10,2)` refuses either infinity with `22003 numeric field overflow`
      * while still taking `NaN`, and `integer`/`bigint` refuse all three.
      *
-     * So `numeric` in `{ mode: 'number' }` states `allowsInfinity: false` deliberately, and it is a
-     * narrowing rather than an oversight: nothing here reads a column's precision or scale, so the
-     * two `numeric` declarations are indistinguishable, and admitting the infinities would make the
-     * schema promise what the server refuses for the commoner of the two.
+     * So `numeric` in `{ mode: 'number' }` answers each of the two separately: `allowsNaN` at any
+     * width, and `allowsInfinity` only where the declaration carries no precision. That used to be a
+     * flat `false`, and the recorded reason was that nothing here read a column's precision or scale,
+     * so the two declarations were indistinguishable and the narrower answer was the safer one.
+     * `declaredDecimalRange` reads both numbers now, the two are distinguishable, and each says what
+     * its own server does.
      *
-     * Postgres only, today. MySQL refuses all three on a `float`/`double` and silently stores `0.00`
-     * for a `decimal`. SQLite returns both infinities and silently turns `NaN` into NULL, which is
-     * real and is filed on its own: a column needs both halves of that answer or none.
+     * Postgres and Gel. MySQL refuses all three on a `float`/`double`, and on a `decimal` refuses
+     * them outright rather than storing `0.00`: measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`,
+     * all three answer `Incorrect decimal value`. SQLite returns both infinities and silently turns
+     * `NaN` into NULL, which is real and is filed on its own: a column needs both halves of that
+     * answer or none.
+     *
+     * Gel joined on a measurement of its own rather than on being Postgres-backed: a live Gel 7.1
+     * stored `nan`, `inf` and `-inf` in both `std::float32` and `std::float64` and handed all three
+     * back unchanged, through a cast and through a stored property.
      *
      * Absent on every other column, including the string mode of `numeric`, which already carries the
      * same fact as a pattern; see `COLUMN_FORMATS.numeric` in `@drzl/validation-core`.
@@ -489,12 +505,19 @@ declare class SchemaAnalyzer {
      * table also answers for a v1 column and the two answers are identical rather than merely
      * compatible. non-finite-numbers.spec.ts asserts that agreement through the real analyzer.
      *
-     * Postgres only. No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a
-     * `float`/`double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while
-     * silently turning `NaN` into NULL, which is a different answer that has to arrive whole.
+     * No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a `float`/
+     * `double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while silently
+     * turning `NaN` into NULL, which is a different answer that has to arrive whole.
+     *
+     * Gel does belong, and is the fourth and fifth entries. Measured on a live Gel 7.1 rather than
+     * inferred from it being Postgres-backed: both `std::float32` and `std::float64` stored `nan`,
+     * `inf` and `-inf` and handed all three back as `NaN`, `Infinity` and `-Infinity`, through a cast
+     * and again through a stored property. Without them every row of such a column failed validation.
      *
      * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
-     * `Infinity`. `PgNumericNumber` states `infinity: false` on purpose; see `Column.allowsNaN`.
+     * `Infinity`. `PgNumericNumber` is absent because its answer is no longer flat: it takes `NaN` at
+     * any width and an infinity only where no precision is declared, which is a per-column question
+     * this table cannot ask. `columnConstraints` answers it beside the bound that decides it.
      */
     private static readonly PG_NON_FINITE;
     /**

package/dist/index.d.ts

@@ -48,8 +48,16 @@ interface Column {
      *
      * Strings rather than numbers because a 64 bit bound is not representable as a JS number:
      * `9223372036854775807` rounds to `9223372036854775808` the moment it becomes one, so a
-     * numeric field here would silently emit a wrong bound. Absent for floats and for `numeric`,
-     * which have no integer range.
+     * numeric field here would silently emit a wrong bound. A 20 digit `numeric(20,0)` bound is
+     * further past that again.
+     *
+     * Not an integer range, despite the name this field used to be described by. An inexact column
+     * carries one too: a `real` is bounded by the magnitude the database refuses past, and a
+     * `numeric(10,2)` by the width its own declaration states. `integer` says which kind it is, and
+     * saying it is what stops a bounded float schema refusing 1.5.
+     *
+     * Absent where nothing declares a bound: an 8 byte float holds every finite JS number, and a
+     * `numeric` with no precision holds arbitrary precision.
      */
     min?: string;
     max?: string;
@@ -76,14 +84,22 @@ interface Column {
      * does too, but a `numeric(10,2)` refuses either infinity with `22003 numeric field overflow`
      * while still taking `NaN`, and `integer`/`bigint` refuse all three.
      *
-     * So `numeric` in `{ mode: 'number' }` states `allowsInfinity: false` deliberately, and it is a
-     * narrowing rather than an oversight: nothing here reads a column's precision or scale, so the
-     * two `numeric` declarations are indistinguishable, and admitting the infinities would make the
-     * schema promise what the server refuses for the commoner of the two.
+     * So `numeric` in `{ mode: 'number' }` answers each of the two separately: `allowsNaN` at any
+     * width, and `allowsInfinity` only where the declaration carries no precision. That used to be a
+     * flat `false`, and the recorded reason was that nothing here read a column's precision or scale,
+     * so the two declarations were indistinguishable and the narrower answer was the safer one.
+     * `declaredDecimalRange` reads both numbers now, the two are distinguishable, and each says what
+     * its own server does.
      *
-     * Postgres only, today. MySQL refuses all three on a `float`/`double` and silently stores `0.00`
-     * for a `decimal`. SQLite returns both infinities and silently turns `NaN` into NULL, which is
-     * real and is filed on its own: a column needs both halves of that answer or none.
+     * Postgres and Gel. MySQL refuses all three on a `float`/`double`, and on a `decimal` refuses
+     * them outright rather than storing `0.00`: measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`,
+     * all three answer `Incorrect decimal value`. SQLite returns both infinities and silently turns
+     * `NaN` into NULL, which is real and is filed on its own: a column needs both halves of that
+     * answer or none.
+     *
+     * Gel joined on a measurement of its own rather than on being Postgres-backed: a live Gel 7.1
+     * stored `nan`, `inf` and `-inf` in both `std::float32` and `std::float64` and handed all three
+     * back unchanged, through a cast and through a stored property.
      *
      * Absent on every other column, including the string mode of `numeric`, which already carries the
      * same fact as a pattern; see `COLUMN_FORMATS.numeric` in `@drzl/validation-core`.
@@ -489,12 +505,19 @@ declare class SchemaAnalyzer {
      * table also answers for a v1 column and the two answers are identical rather than merely
      * compatible. non-finite-numbers.spec.ts asserts that agreement through the real analyzer.
      *
-     * Postgres only. No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a
-     * `float`/`double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while
-     * silently turning `NaN` into NULL, which is a different answer that has to arrive whole.
+     * No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a `float`/
+     * `double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while silently
+     * turning `NaN` into NULL, which is a different answer that has to arrive whole.
+     *
+     * Gel does belong, and is the fourth and fifth entries. Measured on a live Gel 7.1 rather than
+     * inferred from it being Postgres-backed: both `std::float32` and `std::float64` stored `nan`,
+     * `inf` and `-inf` and handed all three back as `NaN`, `Infinity` and `-Infinity`, through a cast
+     * and again through a stored property. Without them every row of such a column failed validation.
      *
      * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
-     * `Infinity`. `PgNumericNumber` states `infinity: false` on purpose; see `Column.allowsNaN`.
+     * `Infinity`. `PgNumericNumber` is absent because its answer is no longer flat: it takes `NaN` at
+     * any width and an infinity only where no precision is declared, which is a per-column question
+     * this table cannot ask. `columnConstraints` answers it beside the bound that decides it.
      */
     private static readonly PG_NON_FINITE;
     /**

package/dist/index.js

@@ -46,6 +46,7 @@ var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
   "SingleStoreBinary",
   "SingleStoreVarBinary"
 ]);
+var BUFFER_CLASSES = /* @__PURE__ */ new Set(["SQLiteBlobBuffer"]);
 function describeV1Column(column) {
   const codec = column?.codec;
   const dataType = column?.dataType;
@@ -70,6 +71,14 @@ function describeV1Column(column) {
     case "int53":
     case "uint53":
     case "int64": {
+      if (DECIMAL_BIGINT_MODE.test(entityKind)) {
+        out.tsType = "bigint";
+        out.dbType = "NUMERIC";
+        out.integer = true;
+        const range2 = decimalModeRange(column, entityKind, "bigint");
+        if (range2) [out.min, out.max] = range2;
+        break;
+      }
       const range = {
         int8: ["-128", "127"],
         int16: ["-32768", "32767"],
@@ -212,10 +221,11 @@ function describeV1Column(column) {
         out.tsType = "number";
         out.dbType = "NUMERIC";
         out.integer = false;
-        [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
+        const range = decimalModeRange(column, entityKind, "number");
+        if (range) [out.min, out.max] = range;
         if (codec === "numeric:number") {
           out.allowsNaN = true;
-          out.allowsInfinity = false;
+          out.allowsInfinity = !declaredDecimalRange(column);
         }
       } else if (js === "string") {
         out.tsType = "string";
@@ -244,6 +254,28 @@ function declaredLength(column) {
   const n = column?.length ?? column?.config?.length ?? column?.config?.dimensions;
   return typeof n === "number" && Number.isFinite(n) && n > 0 ? n : void 0;
 }
+function declaredDecimalRange(column) {
+  const cfg = column?.config ?? {};
+  const precision = column?.precision ?? cfg.precision;
+  const scale = column?.scale ?? cfg.scale ?? 0;
+  if (typeof precision !== "number" || !Number.isInteger(precision) || precision < 1)
+    return void 0;
+  if (typeof scale !== "number" || !Number.isInteger(scale) || scale < 0) return void 0;
+  const nines = "9".repeat(precision);
+  const max = scale === 0 ? nines : scale < precision ? `${nines.slice(0, precision - scale)}.${nines.slice(precision - scale)}` : `0.${"0".repeat(scale - precision)}${nines}`;
+  return [`-${max}`, max];
+}
+var DECIMAL_NUMBER_MODE = /(?:Numeric|Decimal)Number$/;
+var DECIMAL_BIGINT_MODE = /(?:Numeric|Decimal)BigInt$/;
+var MYSQL_IMPLICIT_DECIMAL_RANGE = ["-9999999999", "9999999999"];
+function decimalModeRange(column, kind, mode) {
+  const declared = declaredDecimalRange(column);
+  if (declared) return declared;
+  if (kind.startsWith("MySql") || kind.startsWith("SingleStore"))
+    return MYSQL_IMPLICIT_DECIMAL_RANGE;
+  if (kind.startsWith("SQLite")) return void 0;
+  return mode === "number" ? JS_SAFE_INTEGER_BOUNDS : void 0;
+}
 var VIEW_CONFIG_FIELDS = {
   "drizzle:Columns": "selectedFields",
   "drizzle:Name": "name",
@@ -541,6 +573,19 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       out.allowsNaN = nonFinite.nan;
       out.allowsInfinity = nonFinite.infinity;
     }
+    if (DECIMAL_NUMBER_MODE.test(ctor)) {
+      const range2 = decimalModeRange(column, ctor, "number");
+      if (range2) [out.min, out.max] = range2;
+      out.integer = false;
+      if (ctor === "PgNumericNumber") {
+        out.allowsNaN = true;
+        out.allowsInfinity = !declaredDecimalRange(column);
+      }
+    } else if (DECIMAL_BIGINT_MODE.test(ctor)) {
+      const range2 = decimalModeRange(column, ctor, "bigint");
+      if (range2) [out.min, out.max] = range2;
+      out.integer = true;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -552,12 +597,36 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           tsType: column?.config?.mode === "timestamp" ? "Date" : "number",
           dbType: "INTEGER"
         };
+      // Both timestamp modes of `integer()`, which are one class and one type. `timestamp` and
+      // `timestamp_ms` differ in the scale of the number on the wire, seconds against
+      // milliseconds, and `mapFromDriverValue` consumes that difference and hands back a `Date`
+      // either way; nothing downstream of the analyzer ever sees the integer. So an arm keyed on
+      // the class covers both, where the mode check that used to answer this fell through the
+      // switch to a default arm testing `config.mode === 'timestamp'` and named only the first.
+      // The second came back `unknown`, and every generator emitted a schema accepting anything.
+      //
+      // `DATE` rather than the `INTEGER` that mode check returned, so the two majors describe the
+      // column identically. `dbType` is read in exactly one place outside this file,
+      // `isIntegerColumn`, which the generators consult only for a `tsType` of `number`, so the
+      // relabel reaches no output. Measured rather than argued: emitting a `Date` column under
+      // both labels, nullable and not, through all five generators gives ten byte-identical pairs.
+      case "SQLiteTimestamp":
+        return { tsType: "Date", dbType: "DATE" };
       case "SQLiteText":
         return { tsType: "string", dbType: "TEXT" };
       case "SQLiteReal":
         return { tsType: "number", dbType: "REAL" };
+      // No 0.4x column is a `SQLiteBlob`: `sqlite-core` builds a `SQLiteBlobBuffer`, a
+      // `SQLiteBlobJson` or a `SQLiteBigInt`, one per mode, and exports no class of this name at
+      // all. The arm answers the hand-built column in sqlite-types.spec.ts and nothing drizzle
+      // produces, which is why a real `blob()` reached neither it nor anything else.
       case "SQLiteBlob":
         return { tsType: "Uint8Array", dbType: "BLOB" };
+      // The class a real `blob()` and `blob({ mode: 'buffer' })` both build. See `BUFFER_CLASSES`
+      // for the measurement; the answers here are v1's own for the same column, so this is the
+      // two majors agreeing rather than a new opinion.
+      case "SQLiteBlobBuffer":
+        return { tsType: "Buffer", dbType: "BYTEA" };
       // SQLite spells a mode as a distinct class rather than as config, so `text({mode:'json'})`
       // is a `SQLiteTextJson` and matched no arm at all: the column came back UNKNOWN, which is
       // wider than the `any` a json column at least used to get.
@@ -784,7 +853,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
         if (/^Gel/i.test(ctor)) {
           if (/BigInt64/i.test(ctor)) return { tsType: "bigint", dbType: "BIGINT" };
           if (/Int53|Integer|SmallInt/i.test(ctor)) return { tsType: "number", dbType: "INTEGER" };
-          if (/Real|DoublePrecision/i.test(ctor)) return { tsType: "number", dbType: "NUMERIC" };
+          if (/DoublePrecision/i.test(ctor)) return { tsType: "number", dbType: "DOUBLE" };
+          if (/Real/i.test(ctor)) return { tsType: "number", dbType: "REAL" };
           if (/Decimal/i.test(ctor)) return { tsType: "string", dbType: "NUMERIC" };
           if (/UUID/i.test(ctor)) return { tsType: "string", dbType: "UUID" };
           if (/Json/i.test(ctor)) return { tsType: "any", dbType: "JSON" };
@@ -835,11 +905,13 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       const v1 = describeV1Column(col);
       const constraints = this.columnConstraints(col);
       if (v1?.shape) delete constraints.maxLength;
-      const sqlKind = String(outerCol?.constructor?.[/* @__PURE__ */ Symbol.for("drizzle:entityKind")] ?? "");
+      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 ctorName = String(col?.constructor?.name ?? "");
-      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : NUMBER_VECTOR_CLASSES.has(ctorName) ? { kind: "numberVector", length: declaredLength(col) } : BIT_STRING_CLASSES.has(ctorName) ? { kind: "bitstring", length: declaredLength(col), exact: true } : GEOMETRIC_CLASS_SHAPES[ctorName];
+      const fallbackShape = dbType === "JSON" || dbType === "JSONB" || col?.config?.mode === "json" ? { kind: "json" } : BYTE_STRING_CLASSES.has(ctorName) ? { kind: "byteString", length: declaredLength(col) } : BUFFER_CLASSES.has(ctorName) ? { kind: "buffer" } : NUMBER_VECTOR_CLASSES.has(ctorName) ? { kind: "numberVector", length: declaredLength(col) } : BIT_STRING_CLASSES.has(ctorName) ? { kind: "bitstring", length: declaredLength(col), exact: true } : GEOMETRIC_CLASS_SHAPES[ctorName];
       if (fallbackShape?.kind === "byteString") delete constraints.maxLength;
       const shape = (v1?.shape ?? fallbackShape)?.kind;
       const finalTs = v1?.tsType ?? tsType;
@@ -1202,11 +1274,29 @@ _SchemaAnalyzer.INEXACT_RANGES = {
   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
+  // Gel, whose `real` is a `std::float32` and whose `doublePrecision` is a `std::float64`. Both
+  // used to be answered by a `/Real|DoublePrecision/i` arm that said NUMERIC and stated nothing
+  // else at all, so a `real` column accepted 1e300 and the server refused it.
+  //
+  // Measured on a live Gel 7.1 (`geldata/gel:7`, sys::get_version_as_str() -> 7.1+08db576)
+  // through the `gel` client, casting each literal so the server parses it, and again through a
+  // stored property on a real object type. The float32 edge is Postgres's exactly, to the double:
+  //
+  //   3.4028234663852886e38   accepted, returned unchanged
+  //   3.4028235677973366e38   accepted, and stored as 3.4028234663852886e38
+  //   3.402823567797337e38    refused, "is out of range for type std::float32"
+  //   1e300                   refused, the same way
+  //
+  // The same value accepted, the same next double up refused, and the same rounding down of the
+  // midpoint, so it takes the constant already here rather than a second name for one number.
+  // float64 took 1e300 and Number.MAX_VALUE faithfully, for the reason no 8 byte float has a
+  // truthful finite bound.
+  GelReal: PG_FLOAT4_RANGE,
+  GelDoublePrecision: null
 };
+// `numeric`/`decimal` in either of its two numeric modes is deliberately not in the table above.
+// Its bound is not a fixed magnitude per class but the precision each column declares for itself,
+// which no table keyed on a class name can hold; see `declaredDecimalRange`.
 /**
  * The Postgres number columns that hold a non-finite double, and which of the three each holds.
  *
@@ -1217,17 +1307,25 @@ _SchemaAnalyzer.INEXACT_RANGES = {
  * table also answers for a v1 column and the two answers are identical rather than merely
  * compatible. non-finite-numbers.spec.ts asserts that agreement through the real analyzer.
  *
- * Postgres only. No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a
- * `float`/`double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while
- * silently turning `NaN` into NULL, which is a different answer that has to arrive whole.
+ * No MySQL, SingleStore or SQLite class belongs here: MySQL refuses all three on a `float`/
+ * `double` and stores `0.00` for a `decimal`, and SQLite returns both infinities while silently
+ * turning `NaN` into NULL, which is a different answer that has to arrive whole.
+ *
+ * Gel does belong, and is the fourth and fifth entries. Measured on a live Gel 7.1 rather than
+ * inferred from it being Postgres-backed: both `std::float32` and `std::float64` stored `nan`,
+ * `inf` and `-inf` and handed all three back as `NaN`, `Infinity` and `-Infinity`, through a cast
+ * and again through a stored property. Without them every row of such a column failed validation.
  *
  * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
- * `Infinity`. `PgNumericNumber` states `infinity: false` on purpose; see `Column.allowsNaN`.
+ * `Infinity`. `PgNumericNumber` is absent because its answer is no longer flat: it takes `NaN` at
+ * any width and an infinity only where no precision is declared, which is a per-column question
+ * this table cannot ask. `columnConstraints` answers it beside the bound that decides it.
  */
 _SchemaAnalyzer.PG_NON_FINITE = {
   PgReal: { nan: true, infinity: true },
   PgDoublePrecision: { nan: true, infinity: true },
-  PgNumericNumber: { nan: true, infinity: false }
+  GelReal: { nan: true, infinity: true },
+  GelDoublePrecision: { nan: true, infinity: true }
 };
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@drzl/analyzer",
-  "version": "1.17.4",
+  "version": "1.17.6",
   "private": false,
   "license": "Apache-2.0",
   "type": "module",