@drzl/analyzer 1.17.2 → 1.17.4

package/dist/index.cjs

@@ -71,10 +71,16 @@ var GEOMETRIC_CLASS_SHAPES = {
   // The object modes. `line({ mode: 'abc' })` is a `PgLineABC` and not a `PgLineObject`, and any
   // mode but `'tuple'` builds the object class: `point({ mode: 'abc' })` is a `PgPointObject` too.
   PgPointObject: { kind: "numberObject", fields: ["x", "y"] },
-  PgLineABC: { kind: "numberObject", fields: ["a", "b", "c"] }
+  PgLineABC: { kind: "numberObject", fields: ["a", "b", "c"] },
+  // `geometry()` and `geometry({ mode: 'xy' })` are two classes, not one class with a flag, and
+  // the fuzzer found both unnamed on this path. Their driver mappers disagree the same way the
+  // point ones do: the default hands back `[1, 2]` and the xy mode hands back `{ x: 1, y: 2 }`.
+  PgGeometry: { kind: "tuple", length: 2 },
+  PgGeometryObject: { kind: "numberObject", fields: ["x", "y"] }
 };
 var V1_ONLY_ENTITY_KINDS = /^(?:MsSql|Cockroach)/;
-var NUMBER_VECTOR_CLASSES = /* @__PURE__ */ new Set(["PgVector", "PgHalfVector"]);
+var NUMBER_VECTOR_CLASSES = /* @__PURE__ */ new Set(["PgVector", "PgHalfVector", "SingleStoreVector"]);
+var BIT_STRING_CLASSES = /* @__PURE__ */ new Set(["PgBinaryVector"]);
 var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
   "MySqlBinary",
   "MySqlVarBinary",
@@ -135,6 +141,10 @@ function describeV1Column(column) {
       out.integer = false;
       out.tsType = "number";
       out.dbType = semantic === "float" ? "REAL" : "DOUBLE";
+      if (codec === "float4" || codec === "float8") {
+        out.allowsNaN = true;
+        out.allowsInfinity = true;
+      }
       break;
     }
     case "uuid":
@@ -244,6 +254,10 @@ function describeV1Column(column) {
         out.dbType = "NUMERIC";
         out.integer = false;
         [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
+        if (codec === "numeric:number") {
+          out.allowsNaN = true;
+          out.allowsInfinity = false;
+        }
       } else if (js === "string") {
         out.tsType = "string";
         out.dbType = codec === "varchar" ? "VARCHAR" : codec === "char" ? "CHAR" : "TEXT";
@@ -563,6 +577,11 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       if (inexact) [out.min, out.max] = inexact;
       out.integer = false;
     }
+    const nonFinite = _SchemaAnalyzer.PG_NON_FINITE[ctor];
+    if (nonFinite) {
+      out.allowsNaN = nonFinite.nan;
+      out.allowsInfinity = nonFinite.infinity;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -632,7 +651,18 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       // one is declared, as the codec path already did for `vector`.
       case "PgVector":
       case "PgHalfVector":
+      case "SingleStoreVector":
         return { tsType: "number[]", dbType: "VECTOR" };
+      // `BIT` rather than `TEXT`, which a first version of this arm returned. v1's codec says `BIT`
+      // for the same column, and the cross-major diff said so: naming the class made ten of its
+      // twelve entries go stale and left `c_bit.dbType` and its nullable twin standing, which is
+      // that check distinguishing a fix from a half fix.
+      case "PgBinaryVector":
+        return { tsType: "string", dbType: "BIT" };
+      case "PgGeometry":
+        return { tsType: "[number, number]", dbType: "GEOMETRY" };
+      case "PgGeometryObject":
+        return { tsType: "{ x: number; y: number }", dbType: "GEOMETRY" };
       case "PgSparseVector":
         return { tsType: "string", dbType: "TEXT" };
       case "PgInteger":
@@ -850,7 +880,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       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) } : 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) } : 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;
@@ -1218,6 +1248,28 @@ _SchemaAnalyzer.INEXACT_RANGES = {
   // column, which Postgres caps far lower: it refuses 2147483648 into a `numeric(10,2)`.
   PgNumericNumber: JS_SAFE_INTEGER_BOUNDS
 };
+/**
+ * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+ *
+ * The class-name half of what `describeV1Column` reads off the codec, and the two must agree: a
+ * fact stated on one path and not the other is a schema that changes when the user upgrades
+ * drizzle, which the cross-major diff in `verify-packed.sh` fails on. These three class names are
+ * the same on both majors, read off real `pgTable` columns on 0.45.2 and on 1.0.0-rc.4, so this
+ * 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.
+ *
+ * `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`.
+ */
+_SchemaAnalyzer.PG_NON_FINITE = {
+  PgReal: { nan: true, infinity: true },
+  PgDoublePrecision: { nan: true, infinity: true },
+  PgNumericNumber: { nan: true, infinity: false }
+};
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;
 // Annotate the CommonJS export names for ESM import in node:

package/dist/index.d.cts

@@ -62,6 +62,34 @@ interface Column {
      * generators fall back to the old inference there.
      */
     integer?: boolean;
+    /**
+     * Whether the column stores and returns `NaN`, and whether it does the same for an infinity.
+     *
+     * A range cannot say this. `>=`/`<=` refuses `Infinity` whatever the two numbers are, and `NaN`
+     * compares false against both ends, so a bounded float column described by its range alone
+     * refused three values Postgres stores in it and hands back on SELECT. That is a read-path
+     * defect: every read of such a row fails validation on a column behaving exactly as documented.
+     * The generators render these as a union beside the range rather than as a wider range.
+     *
+     * Measured against PostgreSQL 18.3 through PGlite, on the bound-parameter path a validator
+     * guards. `real` and `double precision` return all three unchanged. An unconstrained `numeric`
+     * 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.
+     *
+     * 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.
+     *
+     * 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`.
+     */
+    allowsNaN?: boolean;
+    allowsInfinity?: boolean;
     /**
      * A string column whose contents have a shape the database enforces.
      *
@@ -451,6 +479,24 @@ declare class SchemaAnalyzer {
      * `number double` on drizzle v1, which is where these pairings come from.
      */
     private static readonly INEXACT_RANGES;
+    /**
+     * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+     *
+     * The class-name half of what `describeV1Column` reads off the codec, and the two must agree: a
+     * fact stated on one path and not the other is a schema that changes when the user upgrades
+     * drizzle, which the cross-major diff in `verify-packed.sh` fails on. These three class names are
+     * the same on both majors, read off real `pgTable` columns on 0.45.2 and on 1.0.0-rc.4, so this
+     * 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.
+     *
+     * `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`.
+     */
+    private static readonly PG_NON_FINITE;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.d.ts

@@ -62,6 +62,34 @@ interface Column {
      * generators fall back to the old inference there.
      */
     integer?: boolean;
+    /**
+     * Whether the column stores and returns `NaN`, and whether it does the same for an infinity.
+     *
+     * A range cannot say this. `>=`/`<=` refuses `Infinity` whatever the two numbers are, and `NaN`
+     * compares false against both ends, so a bounded float column described by its range alone
+     * refused three values Postgres stores in it and hands back on SELECT. That is a read-path
+     * defect: every read of such a row fails validation on a column behaving exactly as documented.
+     * The generators render these as a union beside the range rather than as a wider range.
+     *
+     * Measured against PostgreSQL 18.3 through PGlite, on the bound-parameter path a validator
+     * guards. `real` and `double precision` return all three unchanged. An unconstrained `numeric`
+     * 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.
+     *
+     * 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.
+     *
+     * 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`.
+     */
+    allowsNaN?: boolean;
+    allowsInfinity?: boolean;
     /**
      * A string column whose contents have a shape the database enforces.
      *
@@ -451,6 +479,24 @@ declare class SchemaAnalyzer {
      * `number double` on drizzle v1, which is where these pairings come from.
      */
     private static readonly INEXACT_RANGES;
+    /**
+     * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+     *
+     * The class-name half of what `describeV1Column` reads off the codec, and the two must agree: a
+     * fact stated on one path and not the other is a schema that changes when the user upgrades
+     * drizzle, which the cross-major diff in `verify-packed.sh` fails on. These three class names are
+     * the same on both majors, read off real `pgTable` columns on 0.45.2 and on 1.0.0-rc.4, so this
+     * 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.
+     *
+     * `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`.
+     */
+    private static readonly PG_NON_FINITE;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.js

@@ -30,10 +30,16 @@ var GEOMETRIC_CLASS_SHAPES = {
   // The object modes. `line({ mode: 'abc' })` is a `PgLineABC` and not a `PgLineObject`, and any
   // mode but `'tuple'` builds the object class: `point({ mode: 'abc' })` is a `PgPointObject` too.
   PgPointObject: { kind: "numberObject", fields: ["x", "y"] },
-  PgLineABC: { kind: "numberObject", fields: ["a", "b", "c"] }
+  PgLineABC: { kind: "numberObject", fields: ["a", "b", "c"] },
+  // `geometry()` and `geometry({ mode: 'xy' })` are two classes, not one class with a flag, and
+  // the fuzzer found both unnamed on this path. Their driver mappers disagree the same way the
+  // point ones do: the default hands back `[1, 2]` and the xy mode hands back `{ x: 1, y: 2 }`.
+  PgGeometry: { kind: "tuple", length: 2 },
+  PgGeometryObject: { kind: "numberObject", fields: ["x", "y"] }
 };
 var V1_ONLY_ENTITY_KINDS = /^(?:MsSql|Cockroach)/;
-var NUMBER_VECTOR_CLASSES = /* @__PURE__ */ new Set(["PgVector", "PgHalfVector"]);
+var NUMBER_VECTOR_CLASSES = /* @__PURE__ */ new Set(["PgVector", "PgHalfVector", "SingleStoreVector"]);
+var BIT_STRING_CLASSES = /* @__PURE__ */ new Set(["PgBinaryVector"]);
 var BYTE_STRING_CLASSES = /* @__PURE__ */ new Set([
   "MySqlBinary",
   "MySqlVarBinary",
@@ -94,6 +100,10 @@ function describeV1Column(column) {
       out.integer = false;
       out.tsType = "number";
       out.dbType = semantic === "float" ? "REAL" : "DOUBLE";
+      if (codec === "float4" || codec === "float8") {
+        out.allowsNaN = true;
+        out.allowsInfinity = true;
+      }
       break;
     }
     case "uuid":
@@ -203,6 +213,10 @@ function describeV1Column(column) {
         out.dbType = "NUMERIC";
         out.integer = false;
         [out.min, out.max] = JS_SAFE_INTEGER_BOUNDS;
+        if (codec === "numeric:number") {
+          out.allowsNaN = true;
+          out.allowsInfinity = false;
+        }
       } else if (js === "string") {
         out.tsType = "string";
         out.dbType = codec === "varchar" ? "VARCHAR" : codec === "char" ? "CHAR" : "TEXT";
@@ -522,6 +536,11 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       if (inexact) [out.min, out.max] = inexact;
       out.integer = false;
     }
+    const nonFinite = _SchemaAnalyzer.PG_NON_FINITE[ctor];
+    if (nonFinite) {
+      out.allowsNaN = nonFinite.nan;
+      out.allowsInfinity = nonFinite.infinity;
+    }
     if (/^(Pg)?UUID$/i.test(ctor) || /Uuid$/i.test(ctor)) out.format = "uuid";
     return out;
   }
@@ -591,7 +610,18 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       // one is declared, as the codec path already did for `vector`.
       case "PgVector":
       case "PgHalfVector":
+      case "SingleStoreVector":
         return { tsType: "number[]", dbType: "VECTOR" };
+      // `BIT` rather than `TEXT`, which a first version of this arm returned. v1's codec says `BIT`
+      // for the same column, and the cross-major diff said so: naming the class made ten of its
+      // twelve entries go stale and left `c_bit.dbType` and its nullable twin standing, which is
+      // that check distinguishing a fix from a half fix.
+      case "PgBinaryVector":
+        return { tsType: "string", dbType: "BIT" };
+      case "PgGeometry":
+        return { tsType: "[number, number]", dbType: "GEOMETRY" };
+      case "PgGeometryObject":
+        return { tsType: "{ x: number; y: number }", dbType: "GEOMETRY" };
       case "PgSparseVector":
         return { tsType: "string", dbType: "TEXT" };
       case "PgInteger":
@@ -809,7 +839,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       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) } : 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) } : 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;
@@ -1177,6 +1207,28 @@ _SchemaAnalyzer.INEXACT_RANGES = {
   // column, which Postgres caps far lower: it refuses 2147483648 into a `numeric(10,2)`.
   PgNumericNumber: JS_SAFE_INTEGER_BOUNDS
 };
+/**
+ * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+ *
+ * The class-name half of what `describeV1Column` reads off the codec, and the two must agree: a
+ * fact stated on one path and not the other is a schema that changes when the user upgrades
+ * drizzle, which the cross-major diff in `verify-packed.sh` fails on. These three class names are
+ * the same on both majors, read off real `pgTable` columns on 0.45.2 and on 1.0.0-rc.4, so this
+ * 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.
+ *
+ * `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`.
+ */
+_SchemaAnalyzer.PG_NON_FINITE = {
+  PgReal: { nan: true, infinity: true },
+  PgDoublePrecision: { nan: true, infinity: true },
+  PgNumericNumber: { nan: true, infinity: false }
+};
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;
 export {

package/package.json

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