@drzl/analyzer 1.20.0 → 1.21.0

package/README.md

@@ -48,10 +48,22 @@ The CLI consumes this analysis to generate validation, services, and routers.
 - 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,
-numberObject, vector, bitstring, customType).
+`isGenerated`, `enumValues`, `maxLength` (characters), `maxBytes` (bytes, 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, numberObject, vector, bitstring, customType).
+
+`maxBytes` is set by MySQL and nothing else. Its TEXT and BLOB families carry their limit in the
+type rather than in a declared length, and count it in bytes: 255 for `tinytext` and `tinyblob`,
+65535 for `text` and `blob`, 16777215 for the medium pair and 4294967295 for the long pair. A
+`varchar(n)` is genuinely n characters and keeps `maxLength`. See
+[the analyzer page](https://use-drzl.github.io/drzl/packages/analyzer) for how the generators
+encode it.
+
+`format` names a pattern in `COLUMN_FORMATS`, and two of its values name a dialect: a
+`bigint({ mode: 'string' })` column is `pgBigint` on Postgres and `mysqlBigint` on MySQL and
+SingleStore, because the two servers really do parse that text differently (`'0x1f'` is 31 on one
+and an error on the other, `'12.5'` is 13 on one and an error on the other). SQL Server carries no
+format for it, since none was measured.
 
 `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.

package/dist/index.cjs

@@ -116,11 +116,15 @@ function describeV1Column(column) {
     case "int8":
     case "uint8":
     case "int16":
+    case "uint16":
     case "int24":
+    case "uint24":
     case "int32":
+    case "uint32":
     case "int53":
     case "uint53":
-    case "int64": {
+    case "int64":
+    case "uint64": {
       if (DECIMAL_BIGINT_MODE.test(entityKind)) {
         out.tsType = "bigint";
         out.dbType = "NUMERIC";
@@ -129,22 +133,44 @@ function describeV1Column(column) {
         if (range2) [out.min, out.max] = range2;
         break;
       }
+      if ((semantic === "int64" || semantic === "uint64") && js === "string") {
+        out.tsType = "string";
+        out.dbType = "BIGINT";
+        if (entityKind.startsWith("Pg")) out.format = "pgBigint";
+        else if (entityKind.startsWith("MySql") || entityKind.startsWith("SingleStore"))
+          out.format = "mysqlBigint";
+        break;
+      }
       const range = {
         int8: ["-128", "127"],
         uint8: ["0", "255"],
         int16: ["-32768", "32767"],
+        uint16: ["0", "65535"],
         int24: ["-8388608", "8388607"],
+        uint24: ["0", "16777215"],
         int32: ["-2147483648", "2147483647"],
+        uint32: ["0", "4294967295"],
         int53: ["-9007199254740991", "9007199254740991"],
         // MySQL `serial` is `bigint unsigned auto_increment`, so it starts at 0 rather than
-        // spanning the signed range.
+        // spanning the signed range. An explicit `bigint({ mode: 'number', unsigned: true })`
+        // states the same semantic and takes the same answer.
         uint53: ["0", "9007199254740991"],
-        int64: ["-9223372036854775808", "9223372036854775807"]
+        int64: ["-9223372036854775808", "9223372036854775807"],
+        uint64: ["0", "18446744073709551615"]
       }[semantic];
       [out.min, out.max] = range;
       out.integer = true;
       out.tsType = js === "bigint" ? "bigint" : "number";
-      out.dbType = semantic === "int8" || semantic === "uint8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
+      out.dbType = {
+        int8: "TINYINT",
+        uint8: "TINYINT",
+        int16: "SMALLINT",
+        uint16: "SMALLINT",
+        int24: "MEDIUMINT",
+        uint24: "MEDIUMINT",
+        int32: "INTEGER",
+        uint32: "INTEGER"
+      }[semantic] ?? "BIGINT";
       break;
     }
     case "year":
@@ -164,6 +190,10 @@ function describeV1Column(column) {
         out.allowsNaN = true;
         out.allowsInfinity = true;
       }
+      if (codec === "float" || codec === "double" || codec === "real" || entityKind.startsWith("SingleStore")) {
+        out.allowsNaN = false;
+        out.allowsInfinity = false;
+      }
       break;
     }
     case "uuid":
@@ -431,6 +461,13 @@ function unknownColumnHint(reason) {
   return "Open an issue naming the column type so it can be modelled, or declare it with .$type<T>() and turn on typedColumns.";
 }
 var _SchemaAnalyzer = class _SchemaAnalyzer {
+  /**
+   * One path or several. The plural exists for drizzle-kit interop: kit's `schema` key names
+   * files in the plural (arrays, globs), and the commonest multi-file layout is a directory of
+   * one file per table with no barrel, so there is no single module to point at. Entries are
+   * concrete files, never globs; expansion is the caller's job, so this class's contract stays
+   * "load exactly these modules and read their exports as one schema".
+   */
   constructor(schemaPath) {
     this.schemaPath = schemaPath;
   }
@@ -652,7 +689,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
     if (typeof length === "number" && Number.isFinite(length) && length > 0) {
       out.maxLength = length;
     }
-    const range = _SchemaAnalyzer.INT_RANGES[ctor];
+    const unsignedRange = column?.config?.unsigned === true ? _SchemaAnalyzer.UNSIGNED_INT_RANGES[ctor] : void 0;
+    const range = unsignedRange ?? _SchemaAnalyzer.INT_RANGES[ctor];
     if (range) {
       [out.min, out.max] = range;
       out.integer = true;
@@ -662,7 +700,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       if (inexact) [out.min, out.max] = inexact;
       out.integer = false;
     }
-    const nonFinite = _SchemaAnalyzer.PG_NON_FINITE[ctor];
+    const nonFinite = _SchemaAnalyzer.NON_FINITE_BY_CLASS[ctor];
     if (nonFinite) {
       out.allowsNaN = nonFinite.nan;
       out.allowsInfinity = nonFinite.infinity;
@@ -907,7 +945,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           }
           if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
-          if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
+          if (/Serial/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
+          if (/Int|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
           if (/Bool|Boolean/i.test(ctor)) return { tsType: "boolean", dbType: "BOOLEAN" };
           if (/TimestampString|DateTimeString|DateString/i.test(ctor))
@@ -931,7 +970,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           }
           if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
-          if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
+          if (/Serial/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
+          if (/Int|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
           if (/Bool|Boolean/i.test(ctor)) return { tsType: "boolean", dbType: "BOOLEAN" };
           if (/TimestampString|DateTimeString|DateString/i.test(ctor))
@@ -1142,31 +1182,85 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
     const fs = await import("fs/promises");
     const path = await import("path");
     const issues = [];
-    const full = path.resolve(process.cwd(), this.schemaPath);
-    try {
-      await fs.access(full);
-    } catch (_e) {
-      issues.push({
-        code: "DRZL_ANL_NOFILE",
-        level: "error",
-        message: `Schema file not found: ${this.schemaPath}`
-      });
-      return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
+    const listed = Array.isArray(this.schemaPath);
+    const inputs = listed ? this.schemaPath : [this.schemaPath];
+    const fulls = inputs.map((p) => path.resolve(process.cwd(), p));
+    let missing = false;
+    for (let i = 0; i < fulls.length; i++) {
+      try {
+        await fs.access(fulls[i]);
+      } catch (_e) {
+        missing = true;
+        issues.push({
+          code: "DRZL_ANL_NOFILE",
+          level: "error",
+          message: `Schema file not found: ${inputs[i]}`
+        });
+      }
     }
-    let mod;
-    try {
-      const { default: jiti } = await import("jiti");
-      const jit = jiti(import_meta.url, { moduleCache: false });
-      mod = jit(full);
-    } catch (e) {
-      issues.push({
-        code: "DRZL_ANL_IMPORT",
-        level: "error",
-        message: `Failed to import schema: ${String(e)}`
-      });
+    if (missing) {
       return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
     }
-    const exportsObj = mod?.default && typeof mod.default === "object" ? mod.default : mod;
+    const { default: jiti } = await import("jiti");
+    const jit = jiti(import_meta.url, { moduleCache: false });
+    const exportsObj = {};
+    const exportOrigin = /* @__PURE__ */ new Map();
+    const duplicateDisagreement = (a, b) => {
+      if (Object.is(a, b)) return null;
+      const aCols = this.getSymbol(a, "drizzle:Columns");
+      const bCols = this.getSymbol(b, "drizzle:Columns");
+      if (aCols && bCols) {
+        const aName = this.getSymbol(a, "drizzle:Name");
+        const bName = this.getSymbol(b, "drizzle:Name");
+        const aSchema = this.getSymbol(a, "drizzle:Schema");
+        const bSchema = this.getSymbol(b, "drizzle:Schema");
+        if (aName !== bName || aSchema !== bSchema) {
+          return `two different tables ("${String(aName)}" and "${String(bName)}")`;
+        }
+        if (Object.keys(aCols).join(",") !== Object.keys(bCols).join(",")) {
+          return `two declarations of table "${String(aName)}" with different columns`;
+        }
+        return null;
+      }
+      if (!!aCols !== !!bCols) return "a table and a non-table";
+      const aEnum = a?.enumValues;
+      const bEnum = b?.enumValues;
+      if (Array.isArray(aEnum) && Array.isArray(bEnum)) {
+        return JSON.stringify(aEnum) === JSON.stringify(bEnum) ? null : "two enums with different values";
+      }
+      return null;
+    };
+    for (let i = 0; i < fulls.length; i++) {
+      let mod;
+      try {
+        mod = jit(fulls[i]);
+      } catch (e) {
+        issues.push({
+          code: "DRZL_ANL_IMPORT",
+          level: "error",
+          // The single-path message keeps its historical bytes; a list names the file, since
+          // "the schema" no longer identifies one.
+          message: listed ? `Failed to import schema ${inputs[i]}: ${String(e)}` : `Failed to import schema: ${String(e)}`
+        });
+        return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
+      }
+      const one = mod?.default && typeof mod.default === "object" ? mod.default : mod;
+      for (const [name, val] of Object.entries(one)) {
+        if (!(name in exportsObj)) {
+          exportsObj[name] = val;
+          exportOrigin.set(name, inputs[i]);
+          continue;
+        }
+        const disagreement = duplicateDisagreement(exportsObj[name], val);
+        if (!disagreement) continue;
+        issues.push({
+          code: "DRZL_ANL_DUP_EXPORT",
+          level: "warn",
+          message: `Export "${name}" is ${disagreement}: defined by both ${exportOrigin.get(name)} and ${inputs[i]}; keeping the one in ${exportOrigin.get(name)}.`,
+          path: name
+        });
+      }
+    }
     const tables = [];
     const relations = [];
     const enums = [];
@@ -1319,6 +1413,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
 _SchemaAnalyzer.INT_RANGES = {
   // 8 bit
   MySqlTinyInt: ["-128", "127"],
+  // Absent until the unsigned fix swept the family: v1 states `number int8` for the same
+  // column, so the majors disagreed about every SingleStore tinyint. That is the shape the
+  // cross-major diff in `scripts/verify-packed.sh` exists to catch, and its fixture carries no
+  // SingleStore table, so unsigned-int-ranges.spec.ts holds these two classes across both
+  // majors instead. The width is the type's, the one `MySqlTinyInt` beside it already carries.
+  SingleStoreTinyInt: ["-128", "127"],
   SQLiteInteger: ["-9223372036854775808", "9223372036854775807"],
   // 16 bit
   PgSmallInt: ["-32768", "32767"],
@@ -1331,6 +1431,8 @@ _SchemaAnalyzer.INT_RANGES = {
   SingleStoreSmallInt: ["-32768", "32767"],
   // 24 bit
   MySqlMediumInt: ["-8388608", "8388607"],
+  // As SingleStoreTinyInt above: v1 states `number int24` and this table said nothing.
+  SingleStoreMediumInt: ["-8388608", "8388607"],
   // 32 bit
   PgInteger: ["-2147483648", "2147483647"],
   PgSerial: ["-2147483648", "2147483647"],
@@ -1345,7 +1447,61 @@ _SchemaAnalyzer.INT_RANGES = {
   PgBigInt64: ["-9223372036854775808", "9223372036854775807"],
   PgBigSerial64: ["-9223372036854775808", "9223372036854775807"],
   MySqlBigInt64: ["-9223372036854775808", "9223372036854775807"],
-  SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"]
+  SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"],
+  // MySQL and SingleStore `serial`, which is `bigint unsigned auto_increment`: unsigned by the
+  // builder's own definition, with no `config.unsigned` stating it, so the flag-keyed table
+  // below cannot answer and the range lives here. The mode is number, so the safe-integer
+  // ceiling rather than the column's, exactly as the 53 bit block above. The Postgres serials
+  // stay signed on purpose: a Postgres serial is a plain integer defaulting from a sequence,
+  // and the negative backfill note above applies to them and not to these. Before this entry
+  // the class was in no table at all, so an auto-increment column accepted -1 and the majors
+  // disagreed: v1 states `number uint53` for the same column and was already bounded.
+  MySqlSerial: ["0", "9007199254740991"],
+  SingleStoreSerial: ["0", "9007199254740991"]
+};
+/**
+ * The same widths with `{ unsigned: true }` set, which is the half the table above cannot see.
+ *
+ * On 0.4x the flag moves no class name: `int('x', { unsigned: true })` still builds a
+ * `MySqlInt`, and only `config.unsigned` and the ` unsigned` suffix on `getSQLType()` record
+ * the difference, measured off real 0.45.2 columns. So the table above answered every unsigned
+ * width with its signed range, and the emitted select schema refused every stored value in the
+ * upper half of the column: an `int unsigned` holding 4294967295 failed validation on a row the
+ * database returned, and the same one width up meant `bigint unsigned` refused
+ * 18446744073709551615n.
+ *
+ * The ceilings are the type's, verified against a live MySQL 8.4.11: 255, 65535, 16777215 and
+ * 4294967295 store and return, -1 and each ceiling plus one are refused with
+ * ER_WARN_DATA_OUT_OF_RANGE. The bigint pair keeps the two modes apart for the reason the
+ * signed pair above does: number mode tops out at the safe-integer bound the wire imposes,
+ * bigint mode at the column's own 2^64-1, which a bigint can spell. SingleStore is MySQL wire
+ * compatible, ships the same builders with the same `config.unsigned`, and v1 states the same
+ * `uintN` semantics for it, measured off real rc.4 columns; the entries keep the majors in
+ * agreement, which is what the cross-major diff in `scripts/verify-packed.sh` holds together.
+ *
+ * Keyed by class exactly like `INT_RANGES`, and consulted only when `config.unsigned` is
+ * `true`, so no Postgres or SQLite column can ever reach it: neither dialect has an unsigned
+ * spelling, neither builder accepts the flag, and no class of theirs is named here.
+ */
+_SchemaAnalyzer.UNSIGNED_INT_RANGES = {
+  // 8 bit
+  MySqlTinyInt: ["0", "255"],
+  SingleStoreTinyInt: ["0", "255"],
+  // 16 bit
+  MySqlSmallInt: ["0", "65535"],
+  SingleStoreSmallInt: ["0", "65535"],
+  // 24 bit
+  MySqlMediumInt: ["0", "16777215"],
+  SingleStoreMediumInt: ["0", "16777215"],
+  // 32 bit
+  MySqlInt: ["0", "4294967295"],
+  SingleStoreInt: ["0", "4294967295"],
+  // 53 bit, the JS safe-integer ceiling rather than the column's
+  MySqlBigInt53: ["0", "9007199254740991"],
+  SingleStoreBigInt53: ["0", "9007199254740991"],
+  // 64 bit, representable because the value is a bigint
+  MySqlBigInt64: ["0", "18446744073709551615"],
+  SingleStoreBigInt64: ["0", "18446744073709551615"]
 };
 /**
  * The numeric column classes that are not exact, and the magnitude each one can really hold.
@@ -1420,34 +1576,61 @@ _SchemaAnalyzer.INEXACT_RANGES = {
 // 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.
+ * The number columns whose server has an answer about a non-finite double, and what it is.
+ *
+ * Three states rather than two, and the third is the reason this table has a `false` half at all.
+ * A column present here with `true` stores the value and hands it back, so a schema refusing it
+ * refuses rows the column returns. A column present with `false` is one the server was asked
+ * about and refused, so a schema accepting it promises what the server will not take. A column
+ * *absent* is one nobody has measured, and the generators leave whatever their library does alone
+ * rather than guessing; `nonFiniteAccepted` and `nonFiniteRefused` in `@drzl/validation-core` are
+ * the two readings of that.
  *
  * 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.
+ * drizzle, which the cross-major diff in `verify-packed.sh` fails on. Every class name here is the
+ * same on both majors, read off real 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 and Gel store all three. 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, through a cast and again through a stored property.
+ * Without them every row of such a column failed validation.
  *
- * 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.
+ * MySQL and SingleStore refuse all three, and that used to be left unstated on the reasoning that
+ * a column stating nothing costs nothing. It cost two libraries: `v.number()` and ArkType's
+ * `number` take both infinities where `z.number()` and `Type.Number()` refuse them, so an
+ * unbounded `double` or `real` accepted a value the server answers `ER_WARN_DATA_OUT_OF_RANGE`
+ * for. Measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`, on the binary prepared path, which is
+ * the one that puts the real IEEE double on the wire: `float`, `double` and `real` refuse
+ * `Infinity`, `-Infinity` and `NaN` alike, while `double` and `real` store 1e300 and
+ * 3.4028235e38 unchanged. SingleStore is MySQL wire-compatible and unmeasured, and takes MySQL's
+ * answer here exactly as it already takes MySQL's float32 bound in `INEXACT_RANGES`.
  *
- * 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.
+ * No SQLite class belongs here in either direction. A real SQLite 3.53.4 stores both infinities in
+ * a `real` and hands them back, and silently turns `NaN` into NULL, so it is neither the Postgres
+ * answer nor the MySQL one; it is filed on its own and a column needs both halves of it or none.
  *
- * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
- * `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.
+ * The decimal families are absent too. `PgNumeric` is a string whose pattern already accepts `NaN`
+ * and `Infinity`. `PgNumericNumber` is a per-column question this table cannot ask: it takes `NaN`
+ * at any width and an infinity only where no precision is declared, and `columnConstraints`
+ * answers it beside the bound that decides it. MySQL's `decimal` is absent because the two client
+ * paths disagree: on the binary prepared path MySQL 8.4.11 silently stored `0.00` for all three,
+ * where the text path answers `Incorrect decimal value`, and "refuses" is only half true of a
+ * column that accepted the row.
  */
-_SchemaAnalyzer.PG_NON_FINITE = {
+_SchemaAnalyzer.NON_FINITE_BY_CLASS = {
   PgReal: { nan: true, infinity: true },
   PgDoublePrecision: { nan: true, infinity: true },
   GelReal: { nan: true, infinity: true },
-  GelDoublePrecision: { nan: true, infinity: true }
+  GelDoublePrecision: { nan: true, infinity: true },
+  MySqlFloat: { nan: false, infinity: false },
+  MySqlDouble: { nan: false, infinity: false },
+  MySqlReal: { nan: false, infinity: false },
+  SingleStoreFloat: { nan: false, infinity: false },
+  SingleStoreDouble: { nan: false, infinity: false },
+  SingleStoreReal: { nan: false, infinity: false }
 };
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;

package/dist/index.d.cts

@@ -59,9 +59,11 @@ interface Column {
     /**
      * A coarse label for the column's kind, not its type.
      *
-     * `varchar`, `char` and `text` are all `TEXT` here, deliberately: exactly one consumer reads
-     * this, `isIntegerColumn`, and it only asks whether a number is whole. Use `sqlType` for the
-     * question this name suggests it answers.
+     * `varchar`, `char` and `text` are all `TEXT` here, deliberately: two consumers read this and
+     * both ask coarse questions. `isIntegerColumn` asks whether a number is whole, and
+     * `comparisonWire` in `@drzl/validation-core` asks whether a string wire carries decimal text
+     * the database compares numerically, which is `NUMERIC` (every decimal family) and `BIGINT`
+     * (the v1 string mode). Use `sqlType` for the question this name suggests it answers.
      */
     dbType: string;
     /**
@@ -172,13 +174,18 @@ interface Column {
     /**
      * A string column whose contents have a shape the database enforces.
      *
-     * Only formats checked against Postgres itself appear here, and the list is short because most
+     * Only formats checked against a real server appear here, and the list is short because most
      * candidates failed: Postgres reads `'today'` and `'January 8, 1999'` as dates, pads
      * `'2020-01-01'` into a macaddr, and accepts `'10.1/16'` as an inet. A check for any of those
      * would reject input the database accepts, and turning away valid data is worse than not
      * checking at all. See `COLUMN_FORMATS` in `@drzl/validation-core`.
+     *
+     * Two of the keys name a dialect, because the same column has two different answers: a
+     * `bigint({ mode: 'string' })` is parsed by Postgres as an integer literal, `'0x1f'` and
+     * `'1_000'` included, and by MySQL as a decimal number it then rounds, so `'12.5'` is a row on
+     * one server and an error on the other.
      */
-    format?: 'uuid' | 'numeric';
+    format?: 'uuid' | 'numeric' | 'pgBigint' | 'mysqlBigint';
     /**
      * The column's default, when it is a literal a schema can reproduce.
      *
@@ -474,7 +481,14 @@ declare function isRelationsV2(val: any): boolean;
 declare function readRelationsV2(val: any, issues?: Issue[]): Relation[];
 declare class SchemaAnalyzer {
     private readonly schemaPath;
-    constructor(schemaPath: string);
+    /**
+     * One path or several. The plural exists for drizzle-kit interop: kit's `schema` key names
+     * files in the plural (arrays, globs), and the commonest multi-file layout is a directory of
+     * one file per table with no barrel, so there is no single module to point at. Entries are
+     * concrete files, never globs; expansion is the caller's job, so this class's contract stays
+     * "load exactly these modules and read their exports as one schema".
+     */
+    constructor(schemaPath: string | readonly string[]);
     private getSymbol;
     /**
      * Drizzle keys the Columns object by TypeScript property name, but every other piece of
@@ -564,6 +578,31 @@ declare class SchemaAnalyzer {
      * promise a precision that cannot survive the round trip.
      */
     private static readonly INT_RANGES;
+    /**
+     * The same widths with `{ unsigned: true }` set, which is the half the table above cannot see.
+     *
+     * On 0.4x the flag moves no class name: `int('x', { unsigned: true })` still builds a
+     * `MySqlInt`, and only `config.unsigned` and the ` unsigned` suffix on `getSQLType()` record
+     * the difference, measured off real 0.45.2 columns. So the table above answered every unsigned
+     * width with its signed range, and the emitted select schema refused every stored value in the
+     * upper half of the column: an `int unsigned` holding 4294967295 failed validation on a row the
+     * database returned, and the same one width up meant `bigint unsigned` refused
+     * 18446744073709551615n.
+     *
+     * The ceilings are the type's, verified against a live MySQL 8.4.11: 255, 65535, 16777215 and
+     * 4294967295 store and return, -1 and each ceiling plus one are refused with
+     * ER_WARN_DATA_OUT_OF_RANGE. The bigint pair keeps the two modes apart for the reason the
+     * signed pair above does: number mode tops out at the safe-integer bound the wire imposes,
+     * bigint mode at the column's own 2^64-1, which a bigint can spell. SingleStore is MySQL wire
+     * compatible, ships the same builders with the same `config.unsigned`, and v1 states the same
+     * `uintN` semantics for it, measured off real rc.4 columns; the entries keep the majors in
+     * agreement, which is what the cross-major diff in `scripts/verify-packed.sh` holds together.
+     *
+     * Keyed by class exactly like `INT_RANGES`, and consulted only when `config.unsigned` is
+     * `true`, so no Postgres or SQLite column can ever reach it: neither dialect has an unsigned
+     * spelling, neither builder accepts the flag, and no class of theirs is named here.
+     */
+    private static readonly UNSIGNED_INT_RANGES;
     /**
      * The numeric column classes that are not exact, and the magnitude each one can really hold.
      *
@@ -601,30 +640,51 @@ declare class SchemaAnalyzer {
      */
     private static readonly INEXACT_RANGES;
     /**
-     * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+     * The number columns whose server has an answer about a non-finite double, and what it is.
+     *
+     * Three states rather than two, and the third is the reason this table has a `false` half at all.
+     * A column present here with `true` stores the value and hands it back, so a schema refusing it
+     * refuses rows the column returns. A column present with `false` is one the server was asked
+     * about and refused, so a schema accepting it promises what the server will not take. A column
+     * *absent* is one nobody has measured, and the generators leave whatever their library does alone
+     * rather than guessing; `nonFiniteAccepted` and `nonFiniteRefused` in `@drzl/validation-core` are
+     * the two readings of that.
      *
      * 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.
-     *
-     * 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` 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.
+     * drizzle, which the cross-major diff in `verify-packed.sh` fails on. Every class name here is the
+     * same on both majors, read off real 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 and Gel store all three. 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, through a cast and again through a stored property.
+     * Without them every row of such a column failed validation.
+     *
+     * MySQL and SingleStore refuse all three, and that used to be left unstated on the reasoning that
+     * a column stating nothing costs nothing. It cost two libraries: `v.number()` and ArkType's
+     * `number` take both infinities where `z.number()` and `Type.Number()` refuse them, so an
+     * unbounded `double` or `real` accepted a value the server answers `ER_WARN_DATA_OUT_OF_RANGE`
+     * for. Measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`, on the binary prepared path, which is
+     * the one that puts the real IEEE double on the wire: `float`, `double` and `real` refuse
+     * `Infinity`, `-Infinity` and `NaN` alike, while `double` and `real` store 1e300 and
+     * 3.4028235e38 unchanged. SingleStore is MySQL wire-compatible and unmeasured, and takes MySQL's
+     * answer here exactly as it already takes MySQL's float32 bound in `INEXACT_RANGES`.
+     *
+     * No SQLite class belongs here in either direction. A real SQLite 3.53.4 stores both infinities in
+     * a `real` and hands them back, and silently turns `NaN` into NULL, so it is neither the Postgres
+     * answer nor the MySQL one; it is filed on its own and a column needs both halves of it or none.
+     *
+     * The decimal families are absent too. `PgNumeric` is a string whose pattern already accepts `NaN`
+     * and `Infinity`. `PgNumericNumber` is a per-column question this table cannot ask: it takes `NaN`
+     * at any width and an infinity only where no precision is declared, and `columnConstraints`
+     * answers it beside the bound that decides it. MySQL's `decimal` is absent because the two client
+     * paths disagree: on the binary prepared path MySQL 8.4.11 silently stored `0.00` for all three,
+     * where the text path answers `Incorrect decimal value`, and "refuses" is only half true of a
+     * column that accepted the row.
      */
-    private static readonly PG_NON_FINITE;
+    private static readonly NON_FINITE_BY_CLASS;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.d.ts

@@ -59,9 +59,11 @@ interface Column {
     /**
      * A coarse label for the column's kind, not its type.
      *
-     * `varchar`, `char` and `text` are all `TEXT` here, deliberately: exactly one consumer reads
-     * this, `isIntegerColumn`, and it only asks whether a number is whole. Use `sqlType` for the
-     * question this name suggests it answers.
+     * `varchar`, `char` and `text` are all `TEXT` here, deliberately: two consumers read this and
+     * both ask coarse questions. `isIntegerColumn` asks whether a number is whole, and
+     * `comparisonWire` in `@drzl/validation-core` asks whether a string wire carries decimal text
+     * the database compares numerically, which is `NUMERIC` (every decimal family) and `BIGINT`
+     * (the v1 string mode). Use `sqlType` for the question this name suggests it answers.
      */
     dbType: string;
     /**
@@ -172,13 +174,18 @@ interface Column {
     /**
      * A string column whose contents have a shape the database enforces.
      *
-     * Only formats checked against Postgres itself appear here, and the list is short because most
+     * Only formats checked against a real server appear here, and the list is short because most
      * candidates failed: Postgres reads `'today'` and `'January 8, 1999'` as dates, pads
      * `'2020-01-01'` into a macaddr, and accepts `'10.1/16'` as an inet. A check for any of those
      * would reject input the database accepts, and turning away valid data is worse than not
      * checking at all. See `COLUMN_FORMATS` in `@drzl/validation-core`.
+     *
+     * Two of the keys name a dialect, because the same column has two different answers: a
+     * `bigint({ mode: 'string' })` is parsed by Postgres as an integer literal, `'0x1f'` and
+     * `'1_000'` included, and by MySQL as a decimal number it then rounds, so `'12.5'` is a row on
+     * one server and an error on the other.
      */
-    format?: 'uuid' | 'numeric';
+    format?: 'uuid' | 'numeric' | 'pgBigint' | 'mysqlBigint';
     /**
      * The column's default, when it is a literal a schema can reproduce.
      *
@@ -474,7 +481,14 @@ declare function isRelationsV2(val: any): boolean;
 declare function readRelationsV2(val: any, issues?: Issue[]): Relation[];
 declare class SchemaAnalyzer {
     private readonly schemaPath;
-    constructor(schemaPath: string);
+    /**
+     * One path or several. The plural exists for drizzle-kit interop: kit's `schema` key names
+     * files in the plural (arrays, globs), and the commonest multi-file layout is a directory of
+     * one file per table with no barrel, so there is no single module to point at. Entries are
+     * concrete files, never globs; expansion is the caller's job, so this class's contract stays
+     * "load exactly these modules and read their exports as one schema".
+     */
+    constructor(schemaPath: string | readonly string[]);
     private getSymbol;
     /**
      * Drizzle keys the Columns object by TypeScript property name, but every other piece of
@@ -564,6 +578,31 @@ declare class SchemaAnalyzer {
      * promise a precision that cannot survive the round trip.
      */
     private static readonly INT_RANGES;
+    /**
+     * The same widths with `{ unsigned: true }` set, which is the half the table above cannot see.
+     *
+     * On 0.4x the flag moves no class name: `int('x', { unsigned: true })` still builds a
+     * `MySqlInt`, and only `config.unsigned` and the ` unsigned` suffix on `getSQLType()` record
+     * the difference, measured off real 0.45.2 columns. So the table above answered every unsigned
+     * width with its signed range, and the emitted select schema refused every stored value in the
+     * upper half of the column: an `int unsigned` holding 4294967295 failed validation on a row the
+     * database returned, and the same one width up meant `bigint unsigned` refused
+     * 18446744073709551615n.
+     *
+     * The ceilings are the type's, verified against a live MySQL 8.4.11: 255, 65535, 16777215 and
+     * 4294967295 store and return, -1 and each ceiling plus one are refused with
+     * ER_WARN_DATA_OUT_OF_RANGE. The bigint pair keeps the two modes apart for the reason the
+     * signed pair above does: number mode tops out at the safe-integer bound the wire imposes,
+     * bigint mode at the column's own 2^64-1, which a bigint can spell. SingleStore is MySQL wire
+     * compatible, ships the same builders with the same `config.unsigned`, and v1 states the same
+     * `uintN` semantics for it, measured off real rc.4 columns; the entries keep the majors in
+     * agreement, which is what the cross-major diff in `scripts/verify-packed.sh` holds together.
+     *
+     * Keyed by class exactly like `INT_RANGES`, and consulted only when `config.unsigned` is
+     * `true`, so no Postgres or SQLite column can ever reach it: neither dialect has an unsigned
+     * spelling, neither builder accepts the flag, and no class of theirs is named here.
+     */
+    private static readonly UNSIGNED_INT_RANGES;
     /**
      * The numeric column classes that are not exact, and the magnitude each one can really hold.
      *
@@ -601,30 +640,51 @@ declare class SchemaAnalyzer {
      */
     private static readonly INEXACT_RANGES;
     /**
-     * The Postgres number columns that hold a non-finite double, and which of the three each holds.
+     * The number columns whose server has an answer about a non-finite double, and what it is.
+     *
+     * Three states rather than two, and the third is the reason this table has a `false` half at all.
+     * A column present here with `true` stores the value and hands it back, so a schema refusing it
+     * refuses rows the column returns. A column present with `false` is one the server was asked
+     * about and refused, so a schema accepting it promises what the server will not take. A column
+     * *absent* is one nobody has measured, and the generators leave whatever their library does alone
+     * rather than guessing; `nonFiniteAccepted` and `nonFiniteRefused` in `@drzl/validation-core` are
+     * the two readings of that.
      *
      * 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.
-     *
-     * 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` 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.
+     * drizzle, which the cross-major diff in `verify-packed.sh` fails on. Every class name here is the
+     * same on both majors, read off real 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 and Gel store all three. 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, through a cast and again through a stored property.
+     * Without them every row of such a column failed validation.
+     *
+     * MySQL and SingleStore refuse all three, and that used to be left unstated on the reasoning that
+     * a column stating nothing costs nothing. It cost two libraries: `v.number()` and ArkType's
+     * `number` take both infinities where `z.number()` and `Type.Number()` refuse them, so an
+     * unbounded `double` or `real` accepted a value the server answers `ER_WARN_DATA_OUT_OF_RANGE`
+     * for. Measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`, on the binary prepared path, which is
+     * the one that puts the real IEEE double on the wire: `float`, `double` and `real` refuse
+     * `Infinity`, `-Infinity` and `NaN` alike, while `double` and `real` store 1e300 and
+     * 3.4028235e38 unchanged. SingleStore is MySQL wire-compatible and unmeasured, and takes MySQL's
+     * answer here exactly as it already takes MySQL's float32 bound in `INEXACT_RANGES`.
+     *
+     * No SQLite class belongs here in either direction. A real SQLite 3.53.4 stores both infinities in
+     * a `real` and hands them back, and silently turns `NaN` into NULL, so it is neither the Postgres
+     * answer nor the MySQL one; it is filed on its own and a column needs both halves of it or none.
+     *
+     * The decimal families are absent too. `PgNumeric` is a string whose pattern already accepts `NaN`
+     * and `Infinity`. `PgNumericNumber` is a per-column question this table cannot ask: it takes `NaN`
+     * at any width and an infinity only where no precision is declared, and `columnConstraints`
+     * answers it beside the bound that decides it. MySQL's `decimal` is absent because the two client
+     * paths disagree: on the binary prepared path MySQL 8.4.11 silently stored `0.00` for all three,
+     * where the text path answers `Incorrect decimal value`, and "refuses" is only half true of a
+     * column that accepted the row.
      */
-    private static readonly PG_NON_FINITE;
+    private static readonly NON_FINITE_BY_CLASS;
     /**
      * Constraints the column definition already carries, which the analysis used to throw away.
      *

package/dist/index.js

@@ -73,11 +73,15 @@ function describeV1Column(column) {
     case "int8":
     case "uint8":
     case "int16":
+    case "uint16":
     case "int24":
+    case "uint24":
     case "int32":
+    case "uint32":
     case "int53":
     case "uint53":
-    case "int64": {
+    case "int64":
+    case "uint64": {
       if (DECIMAL_BIGINT_MODE.test(entityKind)) {
         out.tsType = "bigint";
         out.dbType = "NUMERIC";
@@ -86,22 +90,44 @@ function describeV1Column(column) {
         if (range2) [out.min, out.max] = range2;
         break;
       }
+      if ((semantic === "int64" || semantic === "uint64") && js === "string") {
+        out.tsType = "string";
+        out.dbType = "BIGINT";
+        if (entityKind.startsWith("Pg")) out.format = "pgBigint";
+        else if (entityKind.startsWith("MySql") || entityKind.startsWith("SingleStore"))
+          out.format = "mysqlBigint";
+        break;
+      }
       const range = {
         int8: ["-128", "127"],
         uint8: ["0", "255"],
         int16: ["-32768", "32767"],
+        uint16: ["0", "65535"],
         int24: ["-8388608", "8388607"],
+        uint24: ["0", "16777215"],
         int32: ["-2147483648", "2147483647"],
+        uint32: ["0", "4294967295"],
         int53: ["-9007199254740991", "9007199254740991"],
         // MySQL `serial` is `bigint unsigned auto_increment`, so it starts at 0 rather than
-        // spanning the signed range.
+        // spanning the signed range. An explicit `bigint({ mode: 'number', unsigned: true })`
+        // states the same semantic and takes the same answer.
         uint53: ["0", "9007199254740991"],
-        int64: ["-9223372036854775808", "9223372036854775807"]
+        int64: ["-9223372036854775808", "9223372036854775807"],
+        uint64: ["0", "18446744073709551615"]
       }[semantic];
       [out.min, out.max] = range;
       out.integer = true;
       out.tsType = js === "bigint" ? "bigint" : "number";
-      out.dbType = semantic === "int8" || semantic === "uint8" ? "TINYINT" : semantic === "int16" ? "SMALLINT" : semantic === "int24" ? "MEDIUMINT" : semantic === "int32" ? "INTEGER" : "BIGINT";
+      out.dbType = {
+        int8: "TINYINT",
+        uint8: "TINYINT",
+        int16: "SMALLINT",
+        uint16: "SMALLINT",
+        int24: "MEDIUMINT",
+        uint24: "MEDIUMINT",
+        int32: "INTEGER",
+        uint32: "INTEGER"
+      }[semantic] ?? "BIGINT";
       break;
     }
     case "year":
@@ -121,6 +147,10 @@ function describeV1Column(column) {
         out.allowsNaN = true;
         out.allowsInfinity = true;
       }
+      if (codec === "float" || codec === "double" || codec === "real" || entityKind.startsWith("SingleStore")) {
+        out.allowsNaN = false;
+        out.allowsInfinity = false;
+      }
       break;
     }
     case "uuid":
@@ -388,6 +418,13 @@ function unknownColumnHint(reason) {
   return "Open an issue naming the column type so it can be modelled, or declare it with .$type<T>() and turn on typedColumns.";
 }
 var _SchemaAnalyzer = class _SchemaAnalyzer {
+  /**
+   * One path or several. The plural exists for drizzle-kit interop: kit's `schema` key names
+   * files in the plural (arrays, globs), and the commonest multi-file layout is a directory of
+   * one file per table with no barrel, so there is no single module to point at. Entries are
+   * concrete files, never globs; expansion is the caller's job, so this class's contract stays
+   * "load exactly these modules and read their exports as one schema".
+   */
   constructor(schemaPath) {
     this.schemaPath = schemaPath;
   }
@@ -609,7 +646,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
     if (typeof length === "number" && Number.isFinite(length) && length > 0) {
       out.maxLength = length;
     }
-    const range = _SchemaAnalyzer.INT_RANGES[ctor];
+    const unsignedRange = column?.config?.unsigned === true ? _SchemaAnalyzer.UNSIGNED_INT_RANGES[ctor] : void 0;
+    const range = unsignedRange ?? _SchemaAnalyzer.INT_RANGES[ctor];
     if (range) {
       [out.min, out.max] = range;
       out.integer = true;
@@ -619,7 +657,7 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
       if (inexact) [out.min, out.max] = inexact;
       out.integer = false;
     }
-    const nonFinite = _SchemaAnalyzer.PG_NON_FINITE[ctor];
+    const nonFinite = _SchemaAnalyzer.NON_FINITE_BY_CLASS[ctor];
     if (nonFinite) {
       out.allowsNaN = nonFinite.nan;
       out.allowsInfinity = nonFinite.infinity;
@@ -864,7 +902,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           }
           if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
-          if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
+          if (/Serial/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
+          if (/Int|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
           if (/Bool|Boolean/i.test(ctor)) return { tsType: "boolean", dbType: "BOOLEAN" };
           if (/TimestampString|DateTimeString|DateString/i.test(ctor))
@@ -888,7 +927,8 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
           }
           if (/Numeric|Float|Double|Real/i.test(ctor))
             return { tsType: "number", dbType: "NUMERIC" };
-          if (/Int|Serial|TinyInt|SmallInt|MediumInt/i.test(ctor))
+          if (/Serial/i.test(ctor)) return { tsType: "number", dbType: "BIGINT" };
+          if (/Int|TinyInt|SmallInt|MediumInt/i.test(ctor))
             return { tsType: "number", dbType: "INTEGER" };
           if (/Bool|Boolean/i.test(ctor)) return { tsType: "boolean", dbType: "BOOLEAN" };
           if (/TimestampString|DateTimeString|DateString/i.test(ctor))
@@ -1099,31 +1139,85 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
     const fs = await import("fs/promises");
     const path = await import("path");
     const issues = [];
-    const full = path.resolve(process.cwd(), this.schemaPath);
-    try {
-      await fs.access(full);
-    } catch (_e) {
-      issues.push({
-        code: "DRZL_ANL_NOFILE",
-        level: "error",
-        message: `Schema file not found: ${this.schemaPath}`
-      });
-      return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
+    const listed = Array.isArray(this.schemaPath);
+    const inputs = listed ? this.schemaPath : [this.schemaPath];
+    const fulls = inputs.map((p) => path.resolve(process.cwd(), p));
+    let missing = false;
+    for (let i = 0; i < fulls.length; i++) {
+      try {
+        await fs.access(fulls[i]);
+      } catch (_e) {
+        missing = true;
+        issues.push({
+          code: "DRZL_ANL_NOFILE",
+          level: "error",
+          message: `Schema file not found: ${inputs[i]}`
+        });
+      }
     }
-    let mod;
-    try {
-      const { default: jiti } = await import("jiti");
-      const jit = jiti(import.meta.url, { moduleCache: false });
-      mod = jit(full);
-    } catch (e) {
-      issues.push({
-        code: "DRZL_ANL_IMPORT",
-        level: "error",
-        message: `Failed to import schema: ${String(e)}`
-      });
+    if (missing) {
       return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
     }
-    const exportsObj = mod?.default && typeof mod.default === "object" ? mod.default : mod;
+    const { default: jiti } = await import("jiti");
+    const jit = jiti(import.meta.url, { moduleCache: false });
+    const exportsObj = {};
+    const exportOrigin = /* @__PURE__ */ new Map();
+    const duplicateDisagreement = (a, b) => {
+      if (Object.is(a, b)) return null;
+      const aCols = this.getSymbol(a, "drizzle:Columns");
+      const bCols = this.getSymbol(b, "drizzle:Columns");
+      if (aCols && bCols) {
+        const aName = this.getSymbol(a, "drizzle:Name");
+        const bName = this.getSymbol(b, "drizzle:Name");
+        const aSchema = this.getSymbol(a, "drizzle:Schema");
+        const bSchema = this.getSymbol(b, "drizzle:Schema");
+        if (aName !== bName || aSchema !== bSchema) {
+          return `two different tables ("${String(aName)}" and "${String(bName)}")`;
+        }
+        if (Object.keys(aCols).join(",") !== Object.keys(bCols).join(",")) {
+          return `two declarations of table "${String(aName)}" with different columns`;
+        }
+        return null;
+      }
+      if (!!aCols !== !!bCols) return "a table and a non-table";
+      const aEnum = a?.enumValues;
+      const bEnum = b?.enumValues;
+      if (Array.isArray(aEnum) && Array.isArray(bEnum)) {
+        return JSON.stringify(aEnum) === JSON.stringify(bEnum) ? null : "two enums with different values";
+      }
+      return null;
+    };
+    for (let i = 0; i < fulls.length; i++) {
+      let mod;
+      try {
+        mod = jit(fulls[i]);
+      } catch (e) {
+        issues.push({
+          code: "DRZL_ANL_IMPORT",
+          level: "error",
+          // The single-path message keeps its historical bytes; a list names the file, since
+          // "the schema" no longer identifies one.
+          message: listed ? `Failed to import schema ${inputs[i]}: ${String(e)}` : `Failed to import schema: ${String(e)}`
+        });
+        return { dialect: "unknown", tables: [], enums: [], relations: [], issues };
+      }
+      const one = mod?.default && typeof mod.default === "object" ? mod.default : mod;
+      for (const [name, val] of Object.entries(one)) {
+        if (!(name in exportsObj)) {
+          exportsObj[name] = val;
+          exportOrigin.set(name, inputs[i]);
+          continue;
+        }
+        const disagreement = duplicateDisagreement(exportsObj[name], val);
+        if (!disagreement) continue;
+        issues.push({
+          code: "DRZL_ANL_DUP_EXPORT",
+          level: "warn",
+          message: `Export "${name}" is ${disagreement}: defined by both ${exportOrigin.get(name)} and ${inputs[i]}; keeping the one in ${exportOrigin.get(name)}.`,
+          path: name
+        });
+      }
+    }
     const tables = [];
     const relations = [];
     const enums = [];
@@ -1276,6 +1370,12 @@ var _SchemaAnalyzer = class _SchemaAnalyzer {
 _SchemaAnalyzer.INT_RANGES = {
   // 8 bit
   MySqlTinyInt: ["-128", "127"],
+  // Absent until the unsigned fix swept the family: v1 states `number int8` for the same
+  // column, so the majors disagreed about every SingleStore tinyint. That is the shape the
+  // cross-major diff in `scripts/verify-packed.sh` exists to catch, and its fixture carries no
+  // SingleStore table, so unsigned-int-ranges.spec.ts holds these two classes across both
+  // majors instead. The width is the type's, the one `MySqlTinyInt` beside it already carries.
+  SingleStoreTinyInt: ["-128", "127"],
   SQLiteInteger: ["-9223372036854775808", "9223372036854775807"],
   // 16 bit
   PgSmallInt: ["-32768", "32767"],
@@ -1288,6 +1388,8 @@ _SchemaAnalyzer.INT_RANGES = {
   SingleStoreSmallInt: ["-32768", "32767"],
   // 24 bit
   MySqlMediumInt: ["-8388608", "8388607"],
+  // As SingleStoreTinyInt above: v1 states `number int24` and this table said nothing.
+  SingleStoreMediumInt: ["-8388608", "8388607"],
   // 32 bit
   PgInteger: ["-2147483648", "2147483647"],
   PgSerial: ["-2147483648", "2147483647"],
@@ -1302,7 +1404,61 @@ _SchemaAnalyzer.INT_RANGES = {
   PgBigInt64: ["-9223372036854775808", "9223372036854775807"],
   PgBigSerial64: ["-9223372036854775808", "9223372036854775807"],
   MySqlBigInt64: ["-9223372036854775808", "9223372036854775807"],
-  SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"]
+  SingleStoreBigInt64: ["-9223372036854775808", "9223372036854775807"],
+  // MySQL and SingleStore `serial`, which is `bigint unsigned auto_increment`: unsigned by the
+  // builder's own definition, with no `config.unsigned` stating it, so the flag-keyed table
+  // below cannot answer and the range lives here. The mode is number, so the safe-integer
+  // ceiling rather than the column's, exactly as the 53 bit block above. The Postgres serials
+  // stay signed on purpose: a Postgres serial is a plain integer defaulting from a sequence,
+  // and the negative backfill note above applies to them and not to these. Before this entry
+  // the class was in no table at all, so an auto-increment column accepted -1 and the majors
+  // disagreed: v1 states `number uint53` for the same column and was already bounded.
+  MySqlSerial: ["0", "9007199254740991"],
+  SingleStoreSerial: ["0", "9007199254740991"]
+};
+/**
+ * The same widths with `{ unsigned: true }` set, which is the half the table above cannot see.
+ *
+ * On 0.4x the flag moves no class name: `int('x', { unsigned: true })` still builds a
+ * `MySqlInt`, and only `config.unsigned` and the ` unsigned` suffix on `getSQLType()` record
+ * the difference, measured off real 0.45.2 columns. So the table above answered every unsigned
+ * width with its signed range, and the emitted select schema refused every stored value in the
+ * upper half of the column: an `int unsigned` holding 4294967295 failed validation on a row the
+ * database returned, and the same one width up meant `bigint unsigned` refused
+ * 18446744073709551615n.
+ *
+ * The ceilings are the type's, verified against a live MySQL 8.4.11: 255, 65535, 16777215 and
+ * 4294967295 store and return, -1 and each ceiling plus one are refused with
+ * ER_WARN_DATA_OUT_OF_RANGE. The bigint pair keeps the two modes apart for the reason the
+ * signed pair above does: number mode tops out at the safe-integer bound the wire imposes,
+ * bigint mode at the column's own 2^64-1, which a bigint can spell. SingleStore is MySQL wire
+ * compatible, ships the same builders with the same `config.unsigned`, and v1 states the same
+ * `uintN` semantics for it, measured off real rc.4 columns; the entries keep the majors in
+ * agreement, which is what the cross-major diff in `scripts/verify-packed.sh` holds together.
+ *
+ * Keyed by class exactly like `INT_RANGES`, and consulted only when `config.unsigned` is
+ * `true`, so no Postgres or SQLite column can ever reach it: neither dialect has an unsigned
+ * spelling, neither builder accepts the flag, and no class of theirs is named here.
+ */
+_SchemaAnalyzer.UNSIGNED_INT_RANGES = {
+  // 8 bit
+  MySqlTinyInt: ["0", "255"],
+  SingleStoreTinyInt: ["0", "255"],
+  // 16 bit
+  MySqlSmallInt: ["0", "65535"],
+  SingleStoreSmallInt: ["0", "65535"],
+  // 24 bit
+  MySqlMediumInt: ["0", "16777215"],
+  SingleStoreMediumInt: ["0", "16777215"],
+  // 32 bit
+  MySqlInt: ["0", "4294967295"],
+  SingleStoreInt: ["0", "4294967295"],
+  // 53 bit, the JS safe-integer ceiling rather than the column's
+  MySqlBigInt53: ["0", "9007199254740991"],
+  SingleStoreBigInt53: ["0", "9007199254740991"],
+  // 64 bit, representable because the value is a bigint
+  MySqlBigInt64: ["0", "18446744073709551615"],
+  SingleStoreBigInt64: ["0", "18446744073709551615"]
 };
 /**
  * The numeric column classes that are not exact, and the magnitude each one can really hold.
@@ -1377,34 +1533,61 @@ _SchemaAnalyzer.INEXACT_RANGES = {
 // 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.
+ * The number columns whose server has an answer about a non-finite double, and what it is.
+ *
+ * Three states rather than two, and the third is the reason this table has a `false` half at all.
+ * A column present here with `true` stores the value and hands it back, so a schema refusing it
+ * refuses rows the column returns. A column present with `false` is one the server was asked
+ * about and refused, so a schema accepting it promises what the server will not take. A column
+ * *absent* is one nobody has measured, and the generators leave whatever their library does alone
+ * rather than guessing; `nonFiniteAccepted` and `nonFiniteRefused` in `@drzl/validation-core` are
+ * the two readings of that.
  *
  * 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.
+ * drizzle, which the cross-major diff in `verify-packed.sh` fails on. Every class name here is the
+ * same on both majors, read off real 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 and Gel store all three. 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, through a cast and again through a stored property.
+ * Without them every row of such a column failed validation.
  *
- * 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.
+ * MySQL and SingleStore refuse all three, and that used to be left unstated on the reasoning that
+ * a column stating nothing costs nothing. It cost two libraries: `v.number()` and ArkType's
+ * `number` take both infinities where `z.number()` and `Type.Number()` refuse them, so an
+ * unbounded `double` or `real` accepted a value the server answers `ER_WARN_DATA_OUT_OF_RANGE`
+ * for. Measured on MySQL 8.4.11 in `STRICT_TRANS_TABLES`, on the binary prepared path, which is
+ * the one that puts the real IEEE double on the wire: `float`, `double` and `real` refuse
+ * `Infinity`, `-Infinity` and `NaN` alike, while `double` and `real` store 1e300 and
+ * 3.4028235e38 unchanged. SingleStore is MySQL wire-compatible and unmeasured, and takes MySQL's
+ * answer here exactly as it already takes MySQL's float32 bound in `INEXACT_RANGES`.
  *
- * 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.
+ * No SQLite class belongs here in either direction. A real SQLite 3.53.4 stores both infinities in
+ * a `real` and hands them back, and silently turns `NaN` into NULL, so it is neither the Postgres
+ * answer nor the MySQL one; it is filed on its own and a column needs both halves of it or none.
  *
- * `PgNumeric` is absent because its value is a string, and its pattern already accepts `NaN` and
- * `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.
+ * The decimal families are absent too. `PgNumeric` is a string whose pattern already accepts `NaN`
+ * and `Infinity`. `PgNumericNumber` is a per-column question this table cannot ask: it takes `NaN`
+ * at any width and an infinity only where no precision is declared, and `columnConstraints`
+ * answers it beside the bound that decides it. MySQL's `decimal` is absent because the two client
+ * paths disagree: on the binary prepared path MySQL 8.4.11 silently stored `0.00` for all three,
+ * where the text path answers `Incorrect decimal value`, and "refuses" is only half true of a
+ * column that accepted the row.
  */
-_SchemaAnalyzer.PG_NON_FINITE = {
+_SchemaAnalyzer.NON_FINITE_BY_CLASS = {
   PgReal: { nan: true, infinity: true },
   PgDoublePrecision: { nan: true, infinity: true },
   GelReal: { nan: true, infinity: true },
-  GelDoublePrecision: { nan: true, infinity: true }
+  GelDoublePrecision: { nan: true, infinity: true },
+  MySqlFloat: { nan: false, infinity: false },
+  MySqlDouble: { nan: false, infinity: false },
+  MySqlReal: { nan: false, infinity: false },
+  SingleStoreFloat: { nan: false, infinity: false },
+  SingleStoreDouble: { nan: false, infinity: false },
+  SingleStoreReal: { nan: false, infinity: false }
 };
 var SchemaAnalyzer = _SchemaAnalyzer;
 var index_default = SchemaAnalyzer;

package/package.json

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