@quereus/store 4.4.1 → 4.6.0

package/dist/src/common/store-table.d.ts

@@ -8,224 +8,15 @@
  *   - Data store: {schema}.{table} - row data keyed by encoded PK
  *   - Index stores: {schema}.{table}_idx_{name} - one per secondary index
  *   - Stats store: __stats__ - unified store for all table statistics, keyed by {schema}.{table}
- */
-import { VirtualTable, IndexConstraintOp, ConflictResolution, type LogicalType, type Database, type CollationFunction, type CollationResolver, type ColumnSchema, type TableSchema, type TableIndexSchema, type UniqueConstraintSchema, type Row, type FilterInfo, type SqlValue, type VirtualTableConnection, type UpdateArgs, type UpdateResult, type BackingRowChange } from '@quereus/quereus';
-import type { IterateOptions, KVEntry, KVStore } from './kv-store.js';
-import type { StoreEventEmitter } from './events.js';
-import type { TransactionCoordinator } from './transaction.js';
-import { StoreConnection } from './store-connection.js';
-import { type TableStats } from './serialization.js';
-import { type EncodeOptions, type KeyValueTransform } from './encoding.js';
-/**
- * Resolve the per-column KEY collation for each primary-key column.
- *
- * The store encodes PRIMARY KEY uniqueness/ordering PHYSICALLY in the key bytes, so each
- * text-capable PK column's key must be encoded under the collation the engine actually
- * COMPARES that column under. Returns one entry per PK member, in `pkDef` order:
- *   - `isTextual` member (`text`) → its declared `collation` (normalized upper-case), or
- *     `fallback` (the table key collation K) when the column carries none.
- *   - text-capable but not `isTextual` member — `any`, `json`, and the temporal types
- *     (`date` / `time` / `datetime` / `timespan`) → hard-coded `'BINARY'`, see below.
- *   - never-text member → `undefined`: collation is meaningless for
- *     integer/real/blob keys (they encode type-natively), so the encoder ignores
- *     it and the data/index key bytes are identical regardless.
- *
- * Note that `undefined` does NOT mean "encode type-natively" to `encodeValue` — it means
- * "fall back to `options.collation`", the table key collation K. Only a never-text column
- * may be left `undefined`, because only it never reaches the collation branch.
- *
- * Every name returned here is encoded through the key-normalizer resolver carried
- * in `EncodeOptions.normalizers` (`db.getKeyNormalizerResolver()`), so a collation
- * registered or overridden with `db.registerCollation` produces key bytes that agree
- * with the comparator the store's UNIQUE enforcement uses. A collation that cannot
- * key — unregistered, or registered with a comparator but no normalizer — is rejected
- * at DDL time by {@link StoreTable.validateKeyCollations}, so no encode call ever has
- * to fall back. Shared by {@link StoreTable} (data-key + index-maintenance) and
- * `StoreModule.buildIndexEntries` (index rebuild) so the PK suffix encoding can
- * never drift between the two.
- */
-export declare function resolvePkKeyCollations(pkDef: ReadonlyArray<{
-    index: number;
-}>, columns: ReadonlyArray<ColumnSchema>, fallback: string): (string | undefined)[];
-/**
- * The store's per-type key VALUE TRANSFORM for a semantic-ordering logical type, or
- * `undefined` when raw values already key faithfully.
- *
- * The contract is TWO-sided — identity AND order. `StoreTable` implements no
- * `comparePrimaryKey`, so the isolation layer merges overlay against underlying with
- * its own fallback comparator (the PK type's `compare` via `createTypedComparator`)
- * and needs this table's key BYTE order to agree with it; and byte equality must be
- * exactly the type's equality, or two spellings of one value land on two keys.
- *
- *  - JSON → the store-local structural encoder ({@link jsonStructuralKey}): a
- *    `Uint8Array` whose memcmp order reproduces the type's structural `compare`
- *    (canonical-text bytes are identity-faithful but sort `[10]` before `[2]`,
- *    which broke overlay shadowing — see json-key.ts).
- *  - Everything else → the engine's {@link semanticKeyTransform} (the type's
- *    `groupKey`). Today that is TIMESPAN: total seconds against the same reference
- *    date as `TIMESPAN.compare`, so 'PT1H' and 'PT60M' collide on one key AND byte
- *    order is elapsed-time order.
- *
- * JSON deliberately gets NO engine `groupKey` — `groupKey` also drives GROUP BY /
- * `IN` / hash-join identity, where canonical-text identity is already correct and a
- * `Uint8Array` key would be a behaviour change for no benefit. Hence this
- * store-local seam. A semantic-ordering type with NEITHER a `groupKey` nor an entry
- * here cannot key a persisted structure soundly; `StoreTable` rejects it at DDL time
- * (see `validateSemanticKeyTransforms`).
- */
-export declare function storeSemanticKeyTransform(type: LogicalType | undefined): KeyValueTransform | undefined;
-/**
- * Resolve the per-column key value transform for each primary-key column —
- * {@link storeSemanticKeyTransform} of the member's logical type. One entry per PK
- * member in `pkDef` order; `undefined` for every type whose raw value already keys
- * faithfully. The companion of {@link resolvePkKeyCollations}: every call site that
- * threads the collations MUST thread these too, or key identity/order drifts
- * between the write path and the rebuild/lookup path.
- */
-export declare function resolvePkKeyTransforms(pkDef: ReadonlyArray<{
-    index: number;
-}>, columns: ReadonlyArray<ColumnSchema>): (KeyValueTransform | undefined)[];
-/**
- * Per-column key value transforms for a secondary index's OWN columns (the
- * index half of `buildIndexKey`), positionally aligned with `index.columns`.
- * Same rule as {@link resolvePkKeyTransforms}: a semantic-ordering member
- * canonicalizes through {@link storeSemanticKeyTransform}, everything else
- * encodes raw.
- */
-export declare function resolveIndexKeyTransforms(index: TableIndexSchema, columns: ReadonlyArray<ColumnSchema>): (KeyValueTransform | undefined)[];
-/**
- * True when `col` can produce a TEXT value at runtime, and so when its physical
- * key bytes are produced by a collation normalizer rather than a type-native
- * encoding. The `ColumnSchema`-shaped wrapper over the engine's
- * {@link logicalTypeCanHoldText}; both collation-safety guards over the store's
- * secondary indexes — the write-side {@link StoreTable.indexSeekHonorsEnforcementCollation}
- * and the read-side `StoreModule.tryIndexAccessPlan` — exempt a never-text column
- * from their K-vs-C comparison, so a false "non-text" answer is a silent
- * wrong-result (a seek under the wrong collation, with the residual dropped).
- */
-export declare function columnCanHoldText(col: ColumnSchema | undefined): boolean;
-/**
- * True when a byte window — or a byte-order advertisement — over `column` is SOUND.
- *
- * The store physically orders rows by memcmp of each column's key bytes, which for a
- * text-capable column are produced by `keyCollation`'s normalizer. A range seek (and the
- * `providesOrdering` / `monotonicOn` advertisement) equates that byte order with the order
- * `compareCollation`'s comparator defines. Two things must hold for that equation:
- *
- *  - **Same collation on both sides** (`compareCollation === keyCollation`). A `keyCollation`
- *    merely COARSER than `compareCollation` — the relaxation the EQUALITY seek is allowed to
- *    make, see `StoreModule.tryIndexAccessPlan` — is not enough here: it would need the key
- *    normalizer to be monotone with respect to the OTHER collation's order. It generally is
- *    not, even for built-ins: with `keyCollation = NOCASE` and `compareCollation = BINARY`,
- *    'K' (U+212A KELVIN SIGN) is `> 'z'` under BINARY, yet its key bytes are
- *    `toLowerCase('K') = 'k'`, which sorts BEFORE 'z' — the row falls outside a `> 'z'`
- *    window and is silently dropped.
- *  - **The normalizer preserves order** (`db._isCollationOrderPreserving`). `registerCollation`
- *    promises only that a normalizer partitions strings the way the comparator calls them
- *    equal; a custom pair may agree on equality and disagree on order.
- *
- * A never-text column is exempt: its key bytes are type-native and collation-independent.
- *
- * Returning `false` costs an optimization (the caller full-scans and lets the
- * collation-aware `matchesFilters` residual decide); returning `true` wrongly is a silent
- * wrong-result. Shared by `StoreTable`'s read arms and `StoreModule`'s access planner so the
- * "mark handled" and "build a window" decisions can never disagree.
- */
-export declare function keyOrderMatchesCollation(db: Database, column: ColumnSchema | undefined, keyCollation: string, compareCollation: string): boolean;
-/**
- * How many LEADING primary-key members have key bytes whose memcmp order matches their
- * declared collation's comparator order, per {@link keyOrderMatchesCollation}.
- *
- * `pkKeyCollations` is {@link resolvePkKeyCollations}' output for this table; an `undefined`
- * entry belongs to a never-text member, which {@link keyOrderMatchesCollation} exempts
- * outright — `tableKeyCollation` is passed only so the exempt branch has a name to ignore.
- * The comparison collation is the column's declared one, which `reconcilePkCollations` has
- * already aligned with the key collation for every *textual* PK member.
- *
- * What the advertisement is measured against is the order the planner's `Sort` would have
- * produced. For most members Sort orders under the operand's COLLATION, so a collation match
- * is the question; for a member whose logical type carries SEMANTIC ordering (TIMESPAN, JSON
- * — see docs/types.md "Semantic ordering") Sort now ranks by `logicalType.compare`, which no
- * text-byte encoding reproduces, and {@link keyOrderMatchesCollation} closes the gate for
- * such members outright (the memory backend's typed BTree order is the canonical order under
- * that ruling; the store declines rather than advertising a divergent byte order).
- *
- * `0` ⇒ even the leading member is unsafe: no range seek, no PK-order advertisement.
- * A prefix shorter than the PK truncates the ordering advertisement rather than voiding it.
- */
-export declare function pkOrderPreservingPrefixLength(db: Database, schema: TableSchema, pkKeyCollations: ReadonlyArray<string | undefined>, tableKeyCollation: string): number;
-/**
- * Deterministic name of the implicit covering index materialized for a
- * NON-DERIVED UNIQUE constraint `uc`: the constraint's own name when it has one,
- * else the auto-name `_uc_<colNames>`. This MUST equal the engine's
- * `catalog.ts` `implicitIndexName`, so a name that ever reaches the catalog
- * bundle generator is recognized as hidden / exposed-implicit rather than a user
- * index.
- */
-export declare function implicitUniqueIndexName(schema: TableSchema, uc: UniqueConstraintSchema): string;
-/**
- * Return `schema` with a synthetic secondary index materialized into
- * `schema.indexes` for every NON-DERIVED UNIQUE constraint that lacks one — the
- * store analogue of `MemoryTableManager.ensureUniqueConstraintIndexes`.
- *
- * This is what lets a plain column- or table-level `UNIQUE` be enforced by a
- * bounded index point-seek ({@link StoreTable.findUniqueConflictViaIndex})
- * instead of an O(rows) full scan: DML maintenance
- * ({@link StoreTable.updateSecondaryIndexes}) and the UNIQUE check both iterate
- * `schema.indexes`, so once the `_uc_*` entry is present the physical index is
- * maintained and seeked with no new code path.
- *
- * The result is held ONLY in {@link StoreTable.materializedSchema} (the
- * enforcement copy), never in the engine-facing `tableSchema` the store returns
- * from `getSchema()` / registers with the engine. So the read-query planner and
- * the catalog bundle never see `_uc_*` (it is fully derived on open from
- * `uniqueConstraints`); like the memory backend, a plain UNIQUE gets no read-side
- * plan from `_uc_*`, only enforcement / maintenance.
  *
- * Idempotent — a name already present is left untouched — and returns a frozen
- * schema (or the input unchanged when there is nothing to add). A
- * `derivedFromIndex` UC is skipped (its `CREATE UNIQUE INDEX` is already in
- * `schema.indexes`). A partial UNIQUE's synthetic index carries the SAME
- * `uc.predicate` object reference, which
- * {@link StoreTable.findIndexForUniqueConstraint} matches on identity.
+ * The class is layered across four files, each adding one job to the one below:
+ *   `store-table-base.ts`        - state, store handles, stats, transaction lifecycle
+ *   `store-table-scan.ts`        - the read path (predicate -> byte window -> rows)
+ *   `store-table-constraints.ts` - secondary-index maintenance + UNIQUE enforcement
+ *   `store-table.ts`             - this file: the write path and bulk row maintenance
  */
-export declare function withImplicitUniqueIndexes(schema: TableSchema): TableSchema;
-/**
- * Configuration for a store table.
- */
-export interface StoreTableConfig {
-    /** Collation for text keys. Default: 'NOCASE'. */
-    collation?: 'BINARY' | 'NOCASE';
-    /**
-     * Serialized-byte budget for a single index-build write batch (see
-     * `StoreModule.buildIndexEntries`). Parsed from the `max_batch_bytes` module
-     * arg; undefined falls back to the module default.
-     */
-    maxBatchBytes?: number;
-    /** Additional platform-specific options. */
-    [key: string]: unknown;
-}
-/**
- * Interface for the store module that manages this table.
- * Provides access to stores and coordinators.
- */
-export interface StoreTableModule {
-    /** Get the data store for a table. */
-    getStore(schemaName: string, tableName: string, config: StoreTableConfig): Promise<KVStore>;
-    /** Get an index store for a table. */
-    getIndexStore(schemaName: string, tableName: string, indexName: string): Promise<KVStore>;
-    /** Get the stats store for a table. */
-    getStatsStore(schemaName: string, tableName: string): Promise<KVStore>;
-    /**
-     * Get the module's single shared transaction coordinator (one per storage
-     * module, shared by every table — the unit of cross-table atomicity).
-     * Synchronous: ops are addressed by explicit store handle, so obtaining a
-     * coordinator never requires opening storage.
-     */
-    getCoordinator(): TransactionCoordinator;
-    /** Save table DDL to persistent storage. */
-    saveTableDDL(tableSchema: TableSchema): Promise<void>;
-}
+import { type ColumnSchema, type Row, type SqlValue, type UpdateArgs, type UpdateResult, type BackingRowChange } from '@quereus/quereus';
+import { StoreTableConstraints } from './store-table-constraints.js';
 /**
  * One externally-applied row op against a SOURCE table's committed storage,
  * the input vocabulary of {@link StoreTable.applyExternalRowChanges}. An
@@ -247,192 +38,7 @@ export type ExternalRowOp = {
  * storage backends. Platform-specific behavior is delegated to the
  * StoreTableModule.
  */
-export declare class StoreTable extends VirtualTable {
-    protected storeModule: StoreTableModule;
-    protected config: StoreTableConfig;
-    protected store: KVStore | null;
-    protected storeInitPromise: Promise<KVStore> | null;
-    protected indexStores: Map<string, KVStore>;
-    protected statsStore: KVStore | null;
-    protected coordinator: TransactionCoordinator | null;
-    /**
-     * Disposer returned by the coordinator's `registerCallbacks`, captured on the
-     * first {@link attachCoordinator}. Run by {@link dispose} at hard eviction to
-     * deregister this instance's {stats apply/discard} pair from the module-wide
-     * coordinator; null until attached, and nulled again after dispose.
-     */
-    private coordinatorDisposer;
-    protected connection: StoreConnection | null;
-    protected eventEmitter?: StoreEventEmitter;
-    protected encodeOptions: EncodeOptions;
-    protected pkDirections: boolean[];
-    /**
-     * Per-PK-column KEY collation (see {@link resolvePkKeyCollations}). Drives the
-     * physical encoding of every data key and the PK suffix of every secondary-index
-     * key, so a text PK column declared BINARY/NOCASE/RTRIM is keyed under its own
-     * collation rather than one fixed table-level collation. Recomputed on every
-     * {@link updateSchema} (an ALTER COLUMN SET COLLATE on a PK member changes it).
-     */
-    protected pkKeyCollations: (string | undefined)[];
-    /**
-     * Per-PK-column key-identity value transform (see {@link resolvePkKeyTransforms}).
-     * Threaded alongside {@link pkKeyCollations} into every data-key / PK-suffix /
-     * PK-prefix-bounds encode, so a semantic-ordering PK member (TIMESPAN) keys
-     * semantically-equal spellings to one physical key. Recomputed on every
-     * {@link updateSchema}.
-     */
-    protected pkKeyTransforms: (KeyValueTransform | undefined)[];
-    /**
-     * Per-PK-column typed EQUALITY comparator for the semantic-ordering members only —
-     * `undefined` for every other member, which {@link keysEqual} still compares with
-     * strict `!==` as before. Keeps self-PK exclusion and PK-identity questions in
-     * agreement with the physical key identity above ('PT1H' row IS the 'PT60M' row).
-     */
-    protected pkSemanticEquality: (((a: SqlValue, b: SqlValue) => number) | undefined)[];
-    /**
-     * `db.getCollationResolver()`, bound once at construction. Every collation-aware
-     * VALUE comparison this table makes — pushed-constraint re-check, UNIQUE conflict
-     * detection — resolves names through it, so a collation registered with
-     * `db.registerCollation` on *this* connection is honored rather than silently
-     * degraded to BINARY by the process-global built-in registry.
-     *
-     * Only the resolver closure is cached: it reads the live registry, so a collation
-     * registered after connect is still visible. Resolved *functions* are hoisted no
-     * further than the comparator or constraint check that resolved them.
-     *
-     * Its key-bytes counterpart, `db.getKeyNormalizerResolver()`, is bound into
-     * {@link encodeOptions} so the names in {@link pkKeyCollations} resolve to the same
-     * per-connection registry.
-     */
-    protected readonly collationResolver: CollationResolver;
-    protected ddlSaved: boolean;
-    protected cachedStats: TableStats | null;
-    protected pendingStatsDelta: number;
-    protected mutationCount: number;
-    protected statsFlushPending: boolean;
-    private readonly predicateCache;
-    private readonly indexPredicateCache;
-    /**
-     * {@link tableSchema} with a hidden `_uc_*` secondary index materialized per
-     * non-derived UNIQUE constraint (see {@link withImplicitUniqueIndexes}) — the
-     * schema that drives UNIQUE ENFORCEMENT ({@link findIndexForUniqueConstraint})
-     * and physical index MAINTENANCE ({@link updateSecondaryIndexes}).
-     *
-     * Deliberately SEPARATE from the engine-facing {@link tableSchema}: the engine
-     * reads `tableInstance.tableSchema` at CREATE (`SchemaManager.finalizeCreatedTableSchema`)
-     * and the read-query planner reads the registered schema, and NEITHER may see
-     * `_uc_*` (mirrors the memory backend keeping its materialized schema
-     * manager-local; a plain UNIQUE gets no read-side plan from `_uc_*`, only
-     * enforcement). Recomputed alongside `tableSchema` in the constructor and
-     * {@link updateSchema}.
-     */
-    private materializedSchema;
-    constructor(db: Database, storeModule: StoreTableModule, tableSchema: TableSchema, config: StoreTableConfig, eventEmitter?: StoreEventEmitter, isConnected?: boolean);
-    /**
-     * Reject, at DDL time, any collation this table's key encoding would need but cannot
-     * use — before a single row is written under bytes the connection cannot reproduce.
-     *
-     * A collation keys a persisted structure only if it carries a KEY NORMALIZER (the
-     * `(s) => string` whose output equality partitions strings exactly as its comparator
-     * does). `db.registerCollation(name, cmp)` with no `{ normalizer }` gives a collation
-     * that can order rows but not key them; an unregistered name gives nothing at all.
-     * Both raise here rather than at the first insert.
-     *
-     * Checked over exactly the collations the key encoding actually uses:
-     *   - every defined `pkKeyCollations` entry (text-capable PK columns);
-     *   - the table key collation K, but only when it is reachable — a secondary index
-     *     encodes a TEXT-CAPABLE index column's bytes under K (`buildIndexKey`).
-     *
-     * So neither a table with an integer PK and no secondary index, nor one whose every
-     * index column is type-natively keyed, is made unopenable by a K it never encodes with.
-     *
-     * Blast radius: this also fires on catalog rehydration. Reopening a persisted database
-     * from a connection that has not re-registered its custom collation now throws at
-     * CREATE-TABLE-from-catalog rather than silently reading rows under a key layout it
-     * cannot reproduce. See `docs/plugins.md`.
-     *
-     * Takes `pkKeyCollations` rather than reading the field so `updateSchema` can validate
-     * the incoming schema BEFORE it overwrites its own state with it.
-     */
-    private validateKeyCollations;
-    /**
-     * Reject, at DDL time, a key member whose semantic-ordering logical type has no
-     * store key transform — before a single row is keyed under bytes whose order the
-     * type's `compare` (and so the isolation merge, the memory oracle, and Sort)
-     * disagrees with.
-     *
-     * A semantic-ordering type keys soundly only through an order- and
-     * identity-preserving transform ({@link storeSemanticKeyTransform}: the type's
-     * `groupKey`, or a store-local encoder like JSON's structural one). This gap used
-     * to be undetectable — JSON sat here transform-less for a release, keying in
-     * canonical-text order while every comparator ordered structurally, and the only
-     * symptom was a misaligned overlay merge deep inside a transaction. Unreachable
-     * today (TIMESPAN and JSON are both covered); it exists so the NEXT
-     * semantic-ordering type fails loudly at CREATE TABLE instead.
-     *
-     * Checked over the same materialized schema as {@link validateKeyCollations}:
-     * every PK member and every (explicit or hidden `_uc_*`) index column.
-     *
-     * CAVEAT: this can only check that a transform EXISTS — a `groupKey` that is
-     * identity-faithful but not order-preserving passes undetected, so a new type's
-     * transform still needs its byte order argued against its `compare` (see
-     * json-key.ts for the shape of that argument).
-     */
-    private validateSemanticKeyTransforms;
-    /** Get the table configuration. */
-    getConfig(): StoreTableConfig;
-    /** Get the table schema (engine-facing, WITHOUT the hidden `_uc_*` indexes). */
-    getSchema(): TableSchema;
-    /**
-     * Get the enforcement schema — {@link getSchema} plus the hidden `_uc_*`
-     * index materialized per non-derived UNIQUE. Used by the module to resolve the
-     * physical index store to build/tear down during ALTER; never registered with
-     * the engine.
-     */
-    getMaterializedSchema(): TableSchema;
-    /**
-     * Update the table schema after an ALTER TABLE / CREATE INDEX operation.
-     *
-     * Validates the incoming schema's key collations before adopting any of it, so a
-     * rejection leaves this table on its previous, consistent schema.
-     */
-    updateSchema(newSchema: TableSchema): void;
-    /**
-     * Mark the table's DDL as already persisted to the catalog, so the lazy
-     * first-store-access save in {@link initializeStore} is skipped. Called by
-     * `StoreModule.createIndex` / `dropIndex` after they eagerly write the catalog
-     * bundle, so a subsequent INSERT does not redundantly re-persist identical DDL.
-     */
-    markDdlSaved(): void;
-    /** Close and forget a cached index-store handle, if any. */
-    releaseIndexStore(indexName: string): Promise<void>;
-    /**
-     * Returns true if the table has at least one LIVE row — the open transaction's
-     * pending overlay over the committed store. Stops after the first hit.
-     *
-     * Effective (not committed-only) because its one caller, `ADD COLUMN`'s NOT
-     * NULL-without-DEFAULT rejection, must see rows the same transaction inserted:
-     * they are migrated too (the arm DDL-commits before `migrateRows`), and a
-     * committed-only probe would wave them through only to give them a NULL in a
-     * NOT NULL column. Conversely, a pending delete of the last row makes the table
-     * legitimately empty. Reading effectively keeps the check throw-only and
-     * BEFORE the DDL-commit, so a rejection leaves the transaction intact.
-     */
-    hasAnyRows(): Promise<boolean>;
-    /**
-     * Yield the LIVE value of `colIndex` for every row — the open transaction's
-     * pending overlay over the committed store. For throw-only ALTER COLUMN probes
-     * that must run BEFORE the arm's DDL-commit (see `StoreModule.ddlCommitPendingOps`):
-     * they have to see rows this transaction wrote, because those rows are rewritten
-     * too, and a rejection here must leave the transaction intact.
-     */
-    iterateEffectiveValuesAtIndex(colIndex: number): AsyncIterable<SqlValue>;
-    /**
-     * Count the LIVE rows whose column at `colIndex` holds NULL (see
-     * {@link iterateEffectiveValuesAtIndex} for why this reads effectively).
-     * Used by ALTER COLUMN SET NOT NULL to decide whether the tightening is safe.
-     */
-    rowsWithNullAtIndex(colIndex: number): Promise<number>;
+export declare class StoreTable extends StoreTableConstraints {
     /**
      * Apply a per-row mapping function to every stored row, in place (re-writing
      * the same key). The mapper may throw QuereusError — propagated to the caller;
@@ -446,6 +52,64 @@ export declare class StoreTable extends VirtualTable {
      * over the rewritten store at commit.
      */
     mapRowsAtIndex(colIndex: number, mapper: (value: SqlValue) => SqlValue): Promise<void>;
+    /**
+     * Closure computing a row's data key under a NEW primary-key definition and
+     * column set — the exact bytes {@link rekeyRows} pass 2 writes. Shared by
+     * `rekeyRows`' two passes and {@link validateRekeyedPrimaryKey}'s probes so a
+     * collision judged by a probe is byte-identical to the key the re-key would
+     * write. Deliberately NOT the `dedupeRowSignature` / `KeyNormalizerResolver`
+     * path the UNIQUE validators use — the two disagree for at least an `any`-typed
+     * PK member, whose key bytes pin BINARY regardless of its declared collation
+     * (pinned by `any-json-pk-binary-key.spec.ts`).
+     *
+     * The transforms matter too: an ALTER PRIMARY KEY onto (or a SET DATA TYPE
+     * creating) a semantic-ordering member must collapse equal spellings, so
+     * 'PT1H'/'PT60M' land on one key and are judged as the duplicate they are.
+     */
+    private rekeyedKeyComputer;
+    /**
+     * The store's counterpart of the memory backend's
+     * `MemoryTableManager.validateRekeyedPrimaryKey`: the two throw-only questions a
+     * PK re-key must answer, over two DIFFERENT row sets, BEFORE anything is flushed
+     * or mutated (see docs/memory-table.md §"A collation change on a PRIMARY KEY
+     * column obeys a stricter rule"):
+     *
+     *  1. **Is the change legal?** — over `effectiveRows`, the rows the DDL-issuing
+     *     transaction can SEE (a wrapper's `EffectiveRowSource` when the isolation
+     *     layer holds the transaction's staged rows outside this store, else this
+     *     table's own effective stream). Two rows on one new key here is a duplicate
+     *     a `select` in this transaction would return, so the change is invalid →
+     *     `CONSTRAINT`, naming the colliding key.
+     *  2. **Can the store carry it?** — over this store's COMMITTED rows, the set a
+     *     `rollback` must be able to restore. The data store holds one row per key,
+     *     so a committed pair collapsing onto one new key cannot be represented even
+     *     when the transaction has deleted one of them → `BUSY`, with the memory
+     *     module's "commit/rollback and retry" posture.
+     *
+     * Probe order is what makes the statuses right, with no backend sniffing: the
+     * committed probe can only fire once the effective one passed, i.e. only when the
+     * committed rows are NOT a subset of the effective ones — which happens exactly
+     * when the transaction has DELETED a committed row (staged in a wrapper's overlay,
+     * or buffered in this module's own coordinator). A collision among rows the
+     * transaction can still see therefore always reports `CONSTRAINT`, never `BUSY`.
+     *
+     * The buffered-delete case makes the bare module stricter than it used to be: the
+     * old post-flush pass committed the delete first and then re-keyed happily, quietly
+     * spending the transaction's rollback. It now refuses with the same `BUSY` the
+     * wrapped path gives, and `commit; <retry>` still lands the change.
+     *
+     * Both probes key through {@link rekeyedKeyComputer}, so they and the re-key agree
+     * byte-for-byte.
+     *
+     * NOTE: these two probes put the SET COLLATE re-key at four full table scans (two
+     * here, then {@link rekeyRows}' pass 1 backstop and pass 2), each holding one hex
+     * key signature per row. Fine for a statement this rare; if a huge table ever makes
+     * it slow, drop pass 1 for callers that pre-validated — it cannot fire for them.
+     */
+    validateRekeyedPrimaryKey(newPkDef: ReadonlyArray<{
+        index: number;
+        desc?: boolean;
+    }>, newColumns: ReadonlyArray<ColumnSchema>, effectiveRows: AsyncIterable<Row>): Promise<void>;
     /**
      * Re-key every stored row under a new primary-key definition.
      *
@@ -453,7 +117,11 @@ export declare class StoreTable extends VirtualTable {
      * key and retains only a `Set` of key SIGNATURES (hex of the key bytes) to detect
      * collisions — two distinct old keys collapsing to one new key under a coarser
      * collation or a narrower PK. On collision we throw `CONSTRAINT` without touching
-     * the store. The second pass RE-SCANS the same committed store, recomputes each
+     * the store. For `ALTER PRIMARY KEY` this pass is the gate; for `ALTER COLUMN …
+     * SET COLLATE` on a PK member it is only a backstop — that arm has already run
+     * {@link validateRekeyedPrimaryKey}'s two probes before the DDL flush, so a
+     * refusal there leaves the enclosing transaction alive. The second pass RE-SCANS
+     * the same committed store, recomputes each
      * new key, and batches deletes of displaced old keys + puts of new (key, row)
      * pairs into ONE atomic batch. Rows whose new key matches the old key are no-ops.
      *
@@ -504,575 +172,8 @@ export declare class StoreTable extends VirtualTable {
         notNull: boolean;
         columnName: string;
     }): Promise<void>;
-    /**
-     * Ensure the data store is open and DDL is persisted.
-     * Uses a promise-based singleton pattern to prevent race conditions
-     * when multiple concurrent queries access the same table.
-     */
-    protected ensureStore(): Promise<KVStore>;
-    /**
-     * Internal method to actually initialize the store.
-     * Only called once per table instance.
-     */
-    private initializeStore;
-    /**
-     * Get or create an index store for the given index name.
-     */
-    protected ensureIndexStore(indexName: string): Promise<KVStore>;
-    /**
-     * Get or create the stats store.
-     */
-    protected ensureStatsStore(): Promise<KVStore>;
-    /**
-     * Resolve + cache the module's shared TransactionCoordinator and hook the
-     * stats lifecycle callbacks, WITHOUT creating or registering a connection.
-     * Synchronous (the coordinator is handle-addressed, never store-opening — see
-     * `StoreTableModule.getCoordinator`), so the backing host's resolution path can
-     * call it eagerly. Attaching matters for reads: `iterateEffective` /
-     * `readEffectiveRowByKey` consult `this.coordinator` for the pending merge, so a
-     * table whose only writer is the privileged backing host (which queues ops on the
-     * module coordinator, never through `update()`) must still hold the
-     * reference for its read paths to be reads-own-writes.
-     *
-     * The coordinator is module-wide, so its commit/rollback callback array holds
-     * one {stats apply/discard} pair per PARTICIPATING table; each table's
-     * `applyPendingStats` early-returns when its own `pendingStatsDelta` is 0, so a
-     * table that did no work contributes nothing. Registers only on first call per
-     * StoreTable instance (the `if (!this.coordinator)` guard); a fresh instance
-     * after drop+recreate re-registers against the shared coordinator. The OLD
-     * instance is not GC'd on its own — its callback closures capture `this` and
-     * stay pinned on the module-wide coordinator until {@link dispose} runs the
-     * captured disposer (called at the genuine eviction sites, see
-     * `StoreModule.tearDownTableStorage` / `renameTable`).
-     */
-    attachCoordinator(): TransactionCoordinator;
-    /**
-     * Ensure the coordinator is available and connection is registered.
-     */
-    protected ensureCoordinator(): Promise<TransactionCoordinator>;
-    /** Apply pending stats on commit. */
-    protected applyPendingStats(): void;
-    /** Discard pending stats on rollback. */
-    protected discardPendingStats(): void;
-    /** Flush statistics to the stats store. */
-    protected flushStats(): Promise<void>;
-    /** Create a new connection for transaction support. */
-    createConnection(): Promise<VirtualTableConnection>;
-    /** Get the current connection. */
-    getConnection(): VirtualTableConnection | undefined;
-    /** Extract primary key values from a row. */
-    protected extractPK(row: Row): SqlValue[];
-    /**
-     * Coerce each cell in `row` to its declared column logical type.
-     * Mirrors the memory-table path (MemoryTableManager.performInsert/performUpdate)
-     * so INTEGER/REAL affinity is applied and JSON columns are parsed into native
-     * objects before PK extraction, serialization, and index-key construction.
-     */
-    protected coerceRow(row: Row): Row;
-    /**
-     * Query the table with optional filters.
-     *
-     * All three access arms read the EFFECTIVE row state: the committed store
-     * merged with this table's coordinator's pending ops when a transaction is
-     * active (read-your-own-writes — see {@link iterateEffective} /
-     * {@link readLiveRowByPk}). Merged emission stays in encoded-PK-key order,
-     * preserving the module's `providesOrdering` / `monotonicOn` advertisements.
-     */
-    query(filterInfo: FilterInfo): AsyncIterable<Row>;
-    /**
-     * Iterate the effective entry state of this table's data store within
-     * `bounds`: the committed `store.iterate` stream merged with the
-     * coordinator's pending ops for the data store (read-your-own-writes).
-     *
-     * Both inputs are sorted by encoded key bytes, so this is an
-     * order-preserving two-way merge: a pending put wins over a committed entry
-     * at the same key, a pending delete suppresses its committed entry, and
-     * pending puts outside `bounds` are excluded. With no active transaction
-     * (or an empty pending bucket) it degrades to the bare committed iterate.
-     *
-     * The pending side is the module coordinator's bucket for THIS table's data
-     * store handle (`store`) — every data op is queued under that exact handle, so
-     * a sibling table's pending ops (a different data-store handle) never bleed in.
-     */
-    protected iterateEffective(store: KVStore, bounds: IterateOptions, reverse?: boolean): AsyncIterable<KVEntry>;
-    /**
-     * True when a byte window over the LEADING PK column reproduces the comparator's order
-     * — the precondition {@link buildPKRangeBounds} needs, and the exact condition
-     * `StoreModule.computeBestAccessPlan` uses before claiming the range filters handled.
-     * When false, the range arm degrades to a full scan + `matchesFilters` residual.
-     */
-    protected leadingPkRangeIsOrderSafe(): boolean;
-    /**
-     * True when some PK member's logical type carries semantic ordering (TIMESPAN,
-     * JSON). Such PKs decline the point arm and full-scan, where
-     * {@link matchesFilters} applies the type's compare. Historically required —
-     * byte-key equality was a strict subset of the type's equality ('PT1H' ≡
-     * 'PT60M' elapsed-time-equal, byte-distinct) and a point window under-fetched
-     * with no residual able to resurrect a skipped row. Both types' key transforms
-     * (see {@link storeSemanticKeyTransform}) now make byte equality the type's
-     * equality, so the decline is conservative; re-opening is tracked in backlog
-     * `feat-reopen-timespan-store-seeks`. (Range windows and ordering
-     * advertisements are already declined by {@link keyOrderMatchesCollation}.)
-     */
-    protected pkHasSemanticOrderingMember(): boolean;
-    /** Analyze filter info to determine PK access pattern. */
-    protected analyzePKAccess(filterInfo: FilterInfo): PKAccessPattern;
-    /**
-     * Convert a leading-PK-column range access into one seek + early-terminate
-     * iterate window.
-     *
-     * Each LT/LE/GT/GE constraint's bound value is encoded under the SAME
-     * per-column DESC direction and key collation as the data keys (via
-     * {@link encodePkPrefixBounds}), giving the byte region `[lo, hi)` whose
-     * leading column equals that value (`lo = encode([x])`,
-     * `hi = incrementLastByte(lo)`). The op maps that region's endpoints onto a
-     * `gte`/`lt` window; because a DESC column bit-inverts its bytes (larger value
-     * ⇒ smaller bytes), the lower/upper assignment swaps with direction:
-     *
-     *   | op | ASC      | DESC     |
-     *   |----|----------|----------|
-     *   | GE | gte = lo | lt  = hi |
-     *   | GT | gte = hi | lt  = lo |
-     *   | LE | lt  = hi | gte = lo |
-     *   | LT | lt  = lo | gte = hi |
-     *
-     * Across constraints (BETWEEN ⇒ one lower + one upper; a redundant same-side
-     * pair ⇒ the tighter wins) we keep the MAX lower candidate for `gte` and the
-     * MIN upper candidate for `lt`. A candidate that resolves to `undefined` (an
-     * `hi` whose increment overflowed all-0xff) leaves that side unbounded — a safe
-     * SUPERSET, since {@link matchesFilters} stays the authoritative collation-aware
-     * row filter. A NULL/missing bound value is likewise skipped (the planner never
-     * pushes `= NULL`, and a range op against NULL rejects every row in matchesFilters).
-     *
-     * NOTE: a range window over a text PK column is sound only when the column's key
-     * normalizer is ORDER-preserving with respect to its comparator — i.e. the comparator
-     * orders two strings the way memcmp orders their normalized bytes. That is NOT implied
-     * by `db.registerCollation`'s normalizer contract, which promises only an equality
-     * partition, and a built-in NAME may be re-registered with a comparator + normalizer
-     * pair that preserves equality while inverting order. This method is therefore only
-     * ever reached under {@link leadingPkRangeIsOrderSafe} — enforced by
-     * {@link analyzePKAccess} here and mirrored by `StoreModule.computeBestAccessPlan`
-     * before it claims the range filters handled. A collation without the
-     * `orderPreserving` assertion costs the seek, never a row.
-     */
-    protected buildPKRangeBounds(access: PKAccessPattern): IterateOptions;
-    /**
-     * Scan a leading-PK-column range, seeking to the window start and
-     * early-terminating at its end.
-     *
-     * {@link buildPKRangeBounds} converts the LT/LE/GT/GE constraints into one
-     * encoded-byte `gte`/`lt` window under the same per-column DESC directions and
-     * key collations the data keys use, so the iterate visits a SUPERSET of the
-     * qualifying rows (a collation widening or the bound-byte increment can
-     * over-fetch, never under-fetch). {@link matchesFilters} stays the authoritative
-     * collation-aware row filter. {@link iterateEffective} restricts the pending
-     * merge to the same `bounds`, so read-your-own-writes holds on the narrowed window.
-     */
-    protected scanPKRange(store: KVStore, access: PKAccessPattern, filterInfo: FilterInfo): AsyncIterable<Row>;
-    /**
-     * Resolve the secondary index chosen by the planner from `filterInfo.idxStr`.
-     *
-     * The planner emits `idx=<name>(<n>);plan=…` when its access plan set both an
-     * `indexName` and `seekColumnIndexes` (see `getBestAccessPlan` and
-     * rule-select-access-path.ts). Decoding goes through the engine's shared
-     * `decodeIdxStr`, so the store, the in-memory vtab, and the isolation overlay all
-     * read one format. Returns null for the PK/scan sentinels (`_primary_`, `fullscan`,
-     * `empty`), an idxStr that names no index, or a name absent from `schema.indexes` —
-     * every one of which routes back to a PK/full-scan arm.
-     */
-    protected resolveIndexFromIdxStr(idxStr: string | null): TableIndexSchema | null;
-    /**
-     * Analyze filter info to determine a secondary-index access pattern, mirroring
-     * {@link analyzePKAccess} but over the index chosen in `idxStr`.
-     *
-     * A contiguous leading-prefix EQ on the index columns yields a `point` window
-     * (the prefix covers every entry sharing those leading values — an index seek
-     * is a PREFIX scan, not a single row, since the index need not be unique and
-     * the PK suffix varies); otherwise a range (LT/LE/GT/GE) on the LEADING index
-     * column yields a `range` window. Returns null when neither applies or when the
-     * index is unresolved. {@link matchesFilters} stays the authoritative row filter,
-     * so the window need only be a SUPERSET.
-     *
-     * Index-column bytes are encoded under the table key collation K (NOT the index's
-     * per-column declared collation — see `buildIndexKey`), while `matchesFilters` compares
-     * under the index column's effective collation C. The EQ/prefix window is a superset
-     * whenever K is coarser-or-equal to C, which `StoreModule.tryIndexAccessPlan` checked
-     * before it named this index. The RANGE window additionally needs byte order to BE
-     * comparator order, so it is gated on {@link keyOrderMatchesCollation} (which demands
-     * `C === K` plus K's `orderPreserving` assertion); when that fails we return null and
-     * the caller full-scans.
-     */
-    protected analyzeIndexAccess(filterInfo: FilterInfo): IndexAccessPattern | null;
-    /**
-     * True when a byte window over `leadingCol` of `index` reproduces the comparator's
-     * order. Mirrors the range arm of `StoreModule.tryIndexAccessPlan`: the window's bytes
-     * come from the table key collation K, the residual compares under the index column's
-     * effective collation C, so both must be the same order-preserving collation.
-     */
-    protected indexRangeIsOrderSafe(index: TableIndexSchema, leadingCol: number): boolean;
-    /**
-     * Convert leading-index-column LT/LE/GT/GE constraints into one encoded-byte
-     * `gte`/`lt` window — the secondary-index analogue of {@link buildPKRangeBounds}.
-     *
-     * Each bound value is encoded under {@link encodeOptions} (the table key collation K
-     * and its normalizer resolver) and the leading index column's DESC `dir` — exactly as
-     * {@link buildIndexKey} encodes
-     * that column — via {@link buildIndexPrefixBounds}, giving the byte region
-     * `[lo, hi)` whose leading column equals that value. The op maps that region's
-     * endpoints onto `gte`/`lt`, with the same DESC lower/upper SWAP as the PK path:
-     *
-     *   | op | ASC      | DESC     |
-     *   |----|----------|----------|
-     *   | GE | gte = lo | lt  = hi |
-     *   | GT | gte = hi | lt  = lo |
-     *   | LE | lt  = hi | gte = lo |
-     *   | LT | lt  = lo | gte = hi |
-     *
-     * Across constraints keep the MAX lower and MIN upper. An `undefined` upper (an
-     * `hi` whose increment overflowed all-0xff) leaves that side unbounded — a safe
-     * SUPERSET. A NULL/missing bound value is skipped (the planner never pushes
-     * `= NULL`, and a range op against NULL rejects every row in matchesFilters).
-     */
-    protected buildIndexRangeBounds(constraints: Array<{
-        op: IndexConstraintOp;
-        value?: SqlValue;
-    }>, dir: boolean): IterateOptions;
-    /**
-     * Scan a secondary index over `access.bounds`, resolving each index entry to its
-     * base row and re-filtering.
-     *
-     * {@link iterateEffective} yields the committed index entries merged with this
-     * transaction's pending index puts/deletes (read-your-own-writes over the
-     * index), in index-key byte order — the order the isolation overlay merge relies
-     * on (`isolated-table.ts` § buildSortKey). We resolve each entry to its row via
-     * its stored data-key value WITHOUT reordering, so index-key order is preserved.
-     *
-     * Defense in depth mirroring the memory layer's live-recheck: a resolved-null
-     * row (the entry's row was deleted — a pending index delete would normally
-     * suppress the entry, but a committed entry can lag) is skipped, and every
-     * resolved row is re-checked by {@link matchesFilters} (the byte window is only
-     * a superset, and a stale entry whose indexed column no longer matches is
-     * dropped).
-     */
-    protected scanIndex(indexStore: KVStore, access: IndexAccessPattern, filterInfo: FilterInfo): AsyncIterable<Row>;
-    /**
-     * Check if a row matches the filter constraints.
-     *
-     * `collations` maps a constrained column index to the comparison function that
-     * column must be re-checked under; every caller builds it once per scan with
-     * {@link resolveFilterCollations}, whose doc comment explains how the name is
-     * chosen. A column absent from the map compares BINARY — the same result
-     * {@link resolveFilterCollations} produces for an undeclared collation, and the
-     * only reachable absence, since both walk the constraint list under identical
-     * skip conditions.
-     */
-    protected matchesFilters(row: Row, filterInfo: FilterInfo, collations: ReadonlyMap<number, CollationFunction>): boolean;
-    /**
-     * Resolve, ONCE per scan, the comparison collation function for every pushed
-     * constraint column, keyed by column index.
-     *
-     * The name for a column is its DECLARED collation (absent ⇒ BINARY) — the same
-     * resolution the access path's collation-cover analysis uses
-     * (indexColumnCollationLookup / primaryKeyCollationLookup) when it decides a
-     * pushed constraint is fully covered, and the same source this file's UNIQUE
-     * checks compare under. On a collation MATCH the planner drops the residual
-     * Filter, so {@link matchesFilters} alone must reproduce the predicate.
-     *
-     * `indexCollationNames` (from {@link indexColumnCollations}) overrides the
-     * declared name for the secondary-index scan arm: the planner's MATCH there is
-     * against the INDEX column's collation, which an explicit `COLLATE` on the index
-     * can make differ from the table column's.
-     *
-     * Names resolve against {@link collationResolver}, so an unregistered collation
-     * raises `no such collation sequence` at scan setup rather than byte-ordering
-     * every row.
-     *
-     * NOTE: rebuilt on every `query()` / `scanPKRange()` / `scanIndex()` call — one
-     * registry lookup per distinct constrained column, dwarfed by the scan's I/O. If a
-     * point-lookup-heavy profile ever shows it, memoize on the `FilterInfo`.
-     */
-    protected resolveFilterCollations(filterInfo: FilterInfo, indexCollationNames?: ReadonlyMap<number, string | undefined>): ReadonlyMap<number, CollationFunction>;
-    /**
-     * Effective per-column comparison collation for a secondary index's columns:
-     * the index column's own `COLLATE` when present, else the underlying table
-     * column's declared collation. Mirrors the resolution `StoreModule`'s
-     * index-maintenance UNIQUE dedup uses (`indexCol.collation ?? tableColumn`), so
-     * a re-checked index-scan row compares under the same collation the planner used
-     * to justify dropping (or keeping) the residual Filter.
-     */
-    protected indexColumnCollations(index: TableIndexSchema): Map<number, string | undefined>;
-    /**
-     * Compare two values according to an operator, under `collationFunc` (already
-     * resolved by {@link resolveFilterCollations} against this database's collation
-     * registry). So the LT/LE/GT/GE range bounds honour a NOCASE/RTRIM/custom column
-     * collation rather than a raw BINARY JS comparison — the capability
-     * `StoreModule.getBestAccessPlan` advertises via `honorsCollatedRangeBounds`.
-     * NULL on either side fails every operator except EQ-with-both-NULL (the
-     * internal point-lookup convention; the planner never pushes `= NULL`).
-     */
-    protected compareValues(a: SqlValue, op: IndexConstraintOp, b: SqlValue, collationFunc: CollationFunction, semanticCompare?: (a: SqlValue, b: SqlValue) => number): boolean;
     /** Perform an update operation (INSERT, UPDATE, DELETE). */
     update(args: UpdateArgs): Promise<UpdateResult>;
-    /**
-     * Update secondary indexes after a row change.
-     *
-     * For PK-change UPDATE, `oldPk` (where the existing entry lives) and `newPk`
-     * (where the relocated entry will live) differ; using a single pk for both
-     * sides leaks the old entry. Other paths pass the same pk for both.
-     */
-    protected updateSecondaryIndexes(inTransaction: boolean, oldRow: Row | null, newRow: Row | null, oldPk: SqlValue[], newPk?: SqlValue[]): Promise<void>;
-    /**
-     * Returns the compiled predicate for a partial-UNIQUE constraint, or undefined
-     * when the constraint covers the full table. Compilation is memoized per
-     * UniqueConstraintSchema instance so the hot UNIQUE-check path doesn't recompile.
-     */
-    private compileFor;
-    /**
-     * Returns the compiled predicate for a partial secondary index, or undefined
-     * for a full index. Compilation is memoized per IndexSchema instance so the hot
-     * DML index-maintenance path doesn't recompile.
-     */
-    private compileIndexFor;
-    /**
-     * Check if two PK arrays name the same row. A semantic-ordering member compares
-     * through its type's `compare` (see {@link resolvePkSemanticEquality}) so
-     * differently-spelled equal values ('PT1H' / 'PT60M') answer "same row",
-     * agreeing with the physical key identity {@link encodeDataKey} produces; every
-     * other member keeps the original strict `!==`.
-     */
-    protected keysEqual(a: SqlValue[], b: SqlValue[]): boolean;
-    /**
-     * Per-constrained-column comparison functions for one UNIQUE constraint: the
-     * type's `compare` for a semantic-ordering column (so 'PT1H' conflicts with
-     * 'PT60M', matching the memory backend's typed BTree), else the enforcement
-     * collation the caller resolved (`resolveUniqueEnforcementCollations`) through
-     * `compareSqlValuesFast` — the exact comparison every finder used before.
-     *
-     * Thin wrapper over the engine's `uniqueEnforcementComparators`, which memory
-     * and the isolation overlay share so the three backends cannot drift.
-     */
-    private uniqueColumnComparators;
-    /**
-     * Returns true if any column covered by a UNIQUE constraint differs between
-     * oldRow and newRow, or — for partial UNIQUE — any column referenced by the
-     * partial predicate differs (which can transition the row across the
-     * predicate scope and re-trigger the uniqueness check).
-     */
-    protected uniqueColumnsChanged(oldRow: Row, newRow: Row): boolean;
-    /**
-     * Enforce table-level UNIQUE constraints against the prospective newRow.
-     * Honors `onConflict`: IGNORE returns an ok-with-undefined-row; REPLACE
-     * deletes the conflicting row(s) and continues; otherwise returns a
-     * constraint result. Returns null when all constraints pass.
-     *
-     * Rows whose PK is in `selfPks` are skipped (the row being inserted/updated).
-     * NULL in any covered column skips that constraint (multiple NULLs are allowed
-     * per SQL standard).
-     *
-     * Reads through the transaction coordinator's pending writes when active so
-     * intra-transaction duplicates are detected.
-     *
-     * REPLACE evictions (rows at OTHER PKs) are deleted from storage and pushed onto
-     * `evicted` so the DML executor runs the full delete pipeline for each
-     * (change-tracking, row-time MV maintenance, FK cascade, auto-events).
-     */
-    protected checkUniqueConstraints(inTransaction: boolean, newRow: Row, selfPks: SqlValue[][], onConflict: ConflictResolution | undefined, evicted: Row[]): Promise<UpdateResult | null>;
-    /**
-     * Route one UNIQUE constraint's conflict search to the cheapest SOUND finder,
-     * in descending preference:
-     *
-     *  1. A linked row-time covering MV — its backing table (hosted by any
-     *     backing-host-capable module — memory by default, this store module under
-     *     `using store` — queried through the db with reads-own-writes) answers the
-     *     uniqueness question, mirroring the memory enforcement path.
-     *  2. A physical secondary index realizing the constraint — one prefix seek
-     *     instead of a full table scan (see {@link findIndexForUniqueConstraint}).
-     *  3. The full data-store scan ({@link findUniqueConflict}) — always correct,
-     *     O(rows) per checked row.
-     *
-     * Every finder returns the SAME `{pk, row}` shape, so the caller's conflict
-     * action (ABORT / IGNORE / REPLACE eviction) is finder-independent.
-     */
-    private findUniqueConflictFor;
-    /**
-     * The `schema.indexes` entry whose physical index store can serve `uc`'s
-     * conflict search as a point seek, or undefined when none can.
-     *
-     * Every non-derived UNIQUE now carries a materialized implicit index
-     * (`_uc_*`, see {@link withImplicitUniqueIndexes}), so — like the memory
-     * backend — a plain column- or table-level `UNIQUE` is index-servable, not
-     * only an explicit `CREATE INDEX`. A UC is index-servable when:
-     *
-     *  - it is index-derived (`derivedFromIndex`, from `CREATE UNIQUE INDEX`) and
-     *    its named index is still present — the index's partial predicate then
-     *    equals the constraint's by construction (`appendIndexToTableSchema`); or
-     *  - some index's columns equal `uc.columns` positionally AND whose predicate
-     *    is the SAME object as `uc.predicate` (reference identity — the implicit
-     *    materializer sets it that way). For a FULL UNIQUE that is
-     *    `undefined === undefined`, which also admits any user full index over the
-     *    same columns. For a PARTIAL `unique(...) where p` it admits only the
-     *    co-scoped `_uc_*` (which holds exactly the in-scope rows); an arbitrary
-     *    user partial index with a DIFFERENT predicate object stays conservative
-     *    (declined → full scan), because it physically omits rows the constraint
-     *    still covers. The serving index need not be UNIQUE — a plain index over
-     *    the constrained columns still holds every in-scope row.
-     *
-     * Collation guard (see {@link indexSeekHonorsEnforcementCollation}) may still
-     * reject the found index, which routes the check back to the full scan.
-     */
-    private findIndexForUniqueConstraint;
-    /**
-     * True when a point seek into the index realizing `uc` returns a SUPERSET of
-     * the constraint's true conflict set — the only condition under which the
-     * seek may replace the full scan.
-     *
-     * An index key's leading (index-column) bytes are encoded under the TABLE KEY
-     * collation K (`buildIndexKey` passes `this.encodeOptions`), NOT the index's
-     * declared per-column COLLATE and NOT the constraint's enforcement collation
-     * C (`uniqueEnforcementCollations` — the index's per-column COLLATE for an
-     * index-derived UC, else the declared column collation). A seek therefore
-     * fetches exactly `{rows K-equal to newRow}` while the re-validation keeps
-     * `{rows C-equal to newRow}`. Soundness needs
-     * `{C-equal} ⊆ {K-equal}`, i.e. K must be COARSER-OR-EQUAL to C per column:
-     *
-     *  - non-text column → its bytes are type-native, collation-independent: safe.
-     *  - C == K → the sets coincide: safe.
-     *  - K = NOCASE, C = BINARY → K strictly coarser: safe superset.
-     *  - otherwise (K = BINARY over C = NOCASE/RTRIM; K = NOCASE over C = RTRIM)
-     *    the seek UNDER-fetches and a real duplicate would be silently accepted:
-     *    reject, so the caller full-scans.
-     *
-     * Same direction and same admitted cases as the read-side guard in
-     * `StoreModule.tryIndexAccessPlan`; conservative rather than exhaustive
-     * (K = RTRIM over C = BINARY is provably safe but declined), which costs an
-     * optimization, never correctness. The coarseness test is only sound for the
-     * built-in names: a custom K equals a custom C only when the index column names
-     * that same collation, and otherwise falls through to the full scan.
-     */
-    private indexSeekHonorsEnforcementCollation;
-    /**
-     * The index analogue of {@link findUniqueConflict}: seek the index realizing
-     * `uc` at the point formed by `newRow`'s constrained-column values, and
-     * re-validate each resolved candidate exactly as the full scan does.
-     *
-     * The seek encodes ALL of `uc.columns` (positionally aligned with the index's
-     * columns, guaranteed by `appendIndexToTableSchema` / the column-set match in
-     * {@link findIndexForUniqueConstraint}) as a leading prefix of the index key,
-     * under the same key collation and per-column DESC directions
-     * {@link updateSecondaryIndexes} used to write it. The remaining suffix is the
-     * row's PK, so the window spans every entry sharing those column values.
-     * {@link iterateEffective} merges this transaction's pending index puts/deletes
-     * over the committed entries, giving read-your-own-writes; each entry resolves
-     * to its LIVE row through the data key stored as the entry's value.
-     *
-     * The seek only narrows the CANDIDATE set to a superset (guaranteed by
-     * {@link indexSeekHonorsEnforcementCollation}); the authoritative comparison is
-     * the identical self-PK exclusion, per-column enforcement-collation compare,
-     * and partial-predicate scope check the full scan performs. A partial index
-     * already excludes out-of-scope rows physically — the predicate re-check is
-     * kept as defense in depth.
-     *
-     * Returns {@link INDEX_UNUSABLE} rather than a (possibly wrong) answer when an
-     * entry carries a legacy empty value.
-     */
-    private findUniqueConflictViaIndex;
-    /**
-     * Scan committed + pending data rows for a row matching `newRow` on
-     * `uc.columns` whose PK is not in `selfPks`. For partial UNIQUE, candidates
-     * whose row does not satisfy the predicate are skipped. Returns the first
-     * match or null.
-     */
-    private findUniqueConflict;
-    /**
-     * Find a UNIQUE conflict through a linked row-time covering MV's backing table
-     * (the store analogue of the memory `checkUniqueViaMaterializedView`). The
-     * backing scan yields candidate conflicting **source** PKs (reads-own-writes via
-     * the backing's coordinated connection); each is validated against the *live*
-     * store row (committed + this transaction's pending overlay) so a backing entry
-     * that lags a row deleted/updated internally this statement is skipped rather
-     * than raised as a false conflict. Returns the first real conflict or null.
-     */
-    private findUniqueConflictViaCoveringMv;
-    /**
-     * Read the live row at `pk` — this transaction's pending overlay (a pending
-     * delete ⇒ gone; a pending put ⇒ its value) shadowing the committed store.
-     * Backs `query()`'s point-lookup arm and validates covering-MV conflict
-     * candidates against the source of truth.
-     */
-    private readLiveRowByPk;
-    /** Encode `pkValues` (in PK-definition order) exactly as the data store keys rows. */
-    encodeDataKey(pkValues: SqlValue[]): Uint8Array;
-    /**
-     * Byte bounds covering every data key whose leading PK columns equal
-     * `prefixValues` — encoded under the same per-column DESC directions and key
-     * collations as {@link encodeDataKey}, so seek + early-terminate addresses the
-     * exact slice. An empty prefix yields full-scan bounds.
-     */
-    encodePkPrefixBounds(prefixValues: SqlValue[]): {
-        gte: Uint8Array;
-        lt?: Uint8Array;
-    };
-    /**
-     * Effective (pending-over-committed) point read by encoded data key: a pending
-     * delete ⇒ null, a pending put ⇒ its value, else the committed store entry.
-     */
-    readEffectiveRowByKey(key: Uint8Array): Promise<Row | null>;
-    /**
-     * Effective ordered entry scan within `bounds` (see {@link iterateEffective}).
-     * Opens the data store first — which fires the lazy first-access `saveTableDDL`
-     * for a freshly created table, the catalog write a store-backed MV backing
-     * relies on to survive reopen.
-     */
-    iterateEffectiveEntries(bounds: IterateOptions, reverse?: boolean): AsyncIterable<KVEntry>;
-    /** Buffer a privileged row-count delta, applied at coordinator commit (host writes). */
-    trackPrivilegedMutation(delta: number): void;
-    /**
-     * Declared secondary-UNIQUE enforcement for maintenance writes — the store
-     * mirror of the memory manager's `enforceSecondaryUniqueOnMaintenance` (see
-     * `vtab/backing-host.ts` § Constraint validation for the contract and
-     * docs/mv-constraints.md § Derived-row constraint validation for the
-     * semantics). Called by `StoreBackingHost.applyMaintenance` AFTER the op
-     * batch lands in the coordinator's pending state: post-batch is load-bearing
-     * (a `replace-all` diff applies puts before deletes, so a per-op check would
-     * false-positive when the derived set moves a unique value between primary
-     * keys), and checking only the WRITTEN images is complete (pre-existing
-     * contents already satisfied the constraint).
-     *
-     * Reuses {@link findUniqueConflict} — pending-overlay reads, per-column
-     * collations, NULL-pass, partial-predicate scope, self-PK exclusion — with
-     * the covering-MV route deliberately bypassed: a covering MV over THIS table
-     * is cascade-maintained only after the batch returns, so it lags the batch
-     * and would miss a same-batch colliding pair. The conflict action is a hard
-     * abort (a derivation write carries no user OR clause, and a declared
-     * `on conflict replace`/`ignore` default must not evict or drop derived
-     * rows). Per-image cost is one effective full scan: unlike the DML path
-     * ({@link findUniqueConflictFor}), this one is NOT routed through
-     * {@link findUniqueConflictViaIndex}, because a backing table keeps no
-     * secondary indexes by design — there is never an index store to seek.
-     *
-     * Zero overhead when the table declares no secondary UNIQUE (every MV-sugar
-     * backing, and most maintained tables): one empty-array check.
-     */
-    enforceSecondaryUniqueForMaintenance(changes: readonly BackingRowChange[]): Promise<void>;
-    /**
-     * Reset statistics to an absolute committed row count and flush immediately.
-     * Used by the host's `replaceContents` (create-fill / refresh), where the new
-     * count is exact, replacing any drifted delta-tracked estimate.
-     */
-    resetStats(rowCount: number): Promise<void>;
-    /**
-     * Open (and cache) the data store, firing the lazy first-access `saveTableDDL`.
-     * Public for the host's `replaceContents`, which writes the store directly.
-     */
-    openDataStore(): Promise<KVStore>;
-    /**
-     * Effective (pending-over-committed) point read by PK values — the public
-     * read an external writer issues before an upsert to learn the row's current
-     * image. Thin wrapper over the same private point-lookup that backs
-     * {@link query}'s point arm, so an external read merges pending-over-committed
-     * exactly like an engine read does.
-     */
-    readRowByPk(pk: SqlValue[]): Promise<Row | null>;
     /**
      * Apply externally-originated row ops directly to this source table's
      * COMMITTED storage: table-owned data-key put/delete, secondary-index
@@ -1104,79 +205,5 @@ export declare class StoreTable extends VirtualTable {
      * posture the prior raw-KV sync adapter took — not a regression, now stated.
      */
     applyExternalRowChanges(ops: readonly ExternalRowOp[]): Promise<BackingRowChange[]>;
-    /**
-     * Fully delete the row at `pk` (data + secondary indexes + stats + delete event).
-     * Used by REPLACE conflict resolution to evict a conflicting unique row before
-     * the caller's insert/update proceeds.
-     */
-    private deleteRowAt;
-    /**
-     * Begin a table-scoped transaction by ensuring the coordinator is active.
-     *
-     * Used by the isolation layer's flush path, which treats the underlying
-     * write as an independent mini-transaction. Idempotent: if the coordinator
-     * is already in a transaction (e.g. started by a registered connection),
-     * this is a no-op.
-     */
-    begin(): Promise<void>;
-    /**
-     * Commits a table-scoped transaction, flushing any buffered writes to the KV store.
-     * No-op if the coordinator is not currently in a transaction.
-     */
-    commit(): Promise<void>;
-    /**
-     * Rolls back a table-scoped transaction, discarding any buffered writes.
-     * No-op if the coordinator is not currently in a transaction.
-     */
-    rollback(): Promise<void>;
-    /** Disconnect from the store. */
-    disconnect(): Promise<void>;
-    /**
-     * Hard teardown: fully detach this instance from the module-wide coordinator.
-     *
-     * Distinct from the per-scan {@link disconnect} (which only flushes stats and
-     * deliberately keeps the table hooked mid-life). Called ONLY at the genuine
-     * eviction sites — `StoreModule.tearDownTableStorage` (drop / reclaim) and
-     * `renameTable` — where this instance is removed from the module's `tables` map
-     * and will never be used again. It best-effort flushes any buffered stats (the
-     * backing store is about to be deleted / relocated, so this is the last chance,
-     * same posture as the teardown-time `disconnect` it replaces), then runs the
-     * coordinator disposer so this instance's {stats apply/discard} callback pair —
-     * and the `this` its closures capture — is spliced off the shared coordinator's
-     * array rather than pinned for the module's lifetime.
-     *
-     * Idempotent: the disposer is run at most once and both it and the coordinator
-     * reference are nulled, so a double-dispose is a no-op and a re-`attachCoordinator`
-     * after dispose registers a fresh pair instead of double-registering.
-     */
-    dispose(): Promise<void>;
-    /** Get the current estimated row count. */
-    getEstimatedRowCount(): Promise<number>;
-    /** Track a mutation and schedule lazy stats persistence. */
-    protected trackMutation(delta: number, inTransaction?: boolean): void;
-}
-/** PK access pattern analysis result. */
-interface PKAccessPattern {
-    type: 'point' | 'range' | 'scan';
-    values?: SqlValue[];
-    columnIndex?: number;
-    constraints?: Array<{
-        columnIndex: number;
-        op: IndexConstraintOp;
-        value?: SqlValue;
-    }>;
-}
-/**
- * Secondary-index access pattern analysis result: the chosen index plus the
- * encoded byte window {@link StoreTable.scanIndex} iterates. `point` is a
- * leading-prefix EQ window, `range` a leading-column LT/LE/GT/GE window; both
- * resolve to a `bounds` scan (an index seek is always a prefix scan, never a
- * single entry).
- */
-interface IndexAccessPattern {
-    index: TableIndexSchema;
-    type: 'point' | 'range';
-    bounds: IterateOptions;
 }
-export {};
 //# sourceMappingURL=store-table.d.ts.map