@quereus/store 4.5.0 → 4.7.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 IdxStrSpec, 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.
+ * 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 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.
- */
-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,635 +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, multi?: MultiSeekWindowContext): AsyncIterable<Row>;
-    /**
-     * Fail loudly on a multi-seek FilterInfo this table cannot serve. The plan already
-     * dropped the residual Filter, and {@link matchesFilters} ANDs every pushed
-     * constraint — so falling through to the scan arm would AND N mutually-exclusive
-     * equalities and return zero rows: a silent wrong answer, not a slow one.
-     */
-    private multiSeekMalformed;
-    /**
-     * Decode a multi-seek FilterInfo into its N seek tuples of width W. Tuple i pairs
-     * `args[i*W … i*W+W-1]` with the same slice of `constraints` (argvIndex runs
-     * 1…N*W in order — see rule-select-access-path's multiSeek emission). A tuple with
-     * a NULL/undefined component is dropped: IN is set membership and a NULL component
-     * matches nothing. The planner pre-reduces literal lists, but a parameter-bound /
-     * mixed-binding list reaches here unreduced, so this skip is the only line of
-     * defense for those.
-     */
-    private decodeMultiSeekTuples;
-    /**
-     * Order one tuple's values to match `keyCols` (the leading index columns, or the
-     * PK definition) using each constraint entry's column. The plan's seek columns and
-     * the constraint list must agree; a tuple that does not cover exactly those
-     * columns is malformed.
-     */
-    private orderTupleValues;
-    /**
-     * Serve a multi-seek (`plan=5`) FilterInfo: one point window per distinct
-     * IN-list tuple, scanned in ascending encoded-key order.
-     *
-     * Window order is not cosmetic. Encoded-byte order IS index-key order (per-column
-     * DESC inversion is baked into the bytes), and the isolation overlay merges an
-     * index scan with its pending rows by (indexKey, PK) — an out-of-order underlying
-     * stream misplaces overlay rows in the output. Two overlap hazards are folded
-     * away before scanning:
-     *   - Tuples whose K-encoded prefix byte-matches (duplicate bound parameters, or
-     *     case variants under a NOCASE table key collation) share ONE window, each
-     *     kept as a residual alternative — see {@link MultiSeekWindowContext} for why
-     *     a single tuple's residual would drop rows when the comparison collation is
-     *     finer than K.
-     *   - A window with no finite upper bound (all-0xff prefix — see
-     *     buildIndexPrefixBounds) contains every later-sorting window outright (any
-     *     key ≥ an all-0xff prefix necessarily starts with it), so those windows fold
-     *     into it instead of re-scanning an overlapping range out of order.
-     *
-     * Emission is lazy per window — `… in (…) limit 1` stops after the first yielded
-     * row without materializing the remaining windows. Each window goes through
-     * {@link scanIndex} → {@link iterateEffective}, so read-your-own-writes and the
-     * stale-entry / deleted-row defenses hold per seek key.
-     */
-    protected scanMultiSeek(spec: IdxStrSpec, filterInfo: FilterInfo): AsyncIterable<Row>;
-    /**
-     * Multi-seek over the PRIMARY key: each tuple is a full PK, resolved by a point
-     * read in ascending encoded-data-key order (the table's native emission order).
-     *
-     * NOT reachable from this module's own plans today: `StoreModule.computeBestAccessPlan`
-     * claims IN-list filters only for secondary indexes (see its EQ_OPS vs EQ_OR_IN_OPS
-     * split and tickets/backlog/feat-store-pk-in-list-multiseek). The branch exists so
-     * a `_primary_` multi-seek arriving from a future plan gets a correct answer rather
-     * than the scan arm's silent zero rows, and it is what PK-IN enablement will build on.
-     */
-    protected scanMultiSeekPrimary(tuples: MultiSeekTuple[], seekWidth: number, 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
@@ -1164,119 +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;
-}
-/** One pushed-constraint entry, as {@link FilterInfo.constraints} carries it. */
-type ConstraintEntry = FilterInfo['constraints'][number];
-/**
- * One multi-seek tuple: its W constraint entries and their bound values, in
- * constraint order (see {@link StoreTable.decodeMultiSeekTuples}).
- */
-interface MultiSeekTuple {
-    entries: ConstraintEntry[];
-    values: SqlValue[];
-}
-/**
- * Per-window context a multi-seek passes to {@link StoreTable.scanIndex} (absent for
- * ordinary single-window scans).
- *
- * `seen` — data-key hexes already YIELDED by an earlier window. Checked before the
- * data-store read (a cross-window duplicate costs no extra `get`), added only on a
- * yield: adding at visit time would let a stale index entry (row re-keyed since
- * indexing) that FAILS its residual poison the set and suppress the row's live entry
- * in a later window.
- * NOTE: holds one hex string per row the multi-seek yields, for the whole seek — the
- * only unbounded allocation on this path. Windows are byte-disjoint, so the only real
- * duplicate source is a stale index entry; if a large-result `IN` ever shows up as a
- * memory problem, the set can be scoped per window (or dropped for a consistent store).
- *
- * `collations` — the constraint collation map, resolved once per multi-seek (it is
- * identical for every window).
- *
- * `extraTuples` — additional seek tuples whose K-encoded window byte-equals this
- * window's (duplicate bound parameters, or case-variant values under a NOCASE table
- * key collation K). A row is yielded when it matches the primary FilterInfo OR any of
- * these: when the column's comparison collation C is strictly finer than K (K=NOCASE
- * over a BINARY column — the one coarser pairing the plan admits), the merged tuples
- * are C-distinct and each admits different rows, so a single tuple's residual would
- * silently drop the other tuples' rows.
- */
-interface MultiSeekWindowContext {
-    seen: Set<string>;
-    collations: ReadonlyMap<number, CollationFunction>;
-    extraTuples: readonly FilterInfo[];
 }
-export {};
 //# sourceMappingURL=store-table.d.ts.map