@quereus/quereus 3.2.1 → 4.0.0

package/dist/src/runtime/emit/materialized-view-helpers.d.ts

@@ -0,0 +1,640 @@
+import type { Database } from '../../core/database.js';
+import { QuereusError } from '../../common/errors.js';
+import { type Row, type SqlValue } from '../../common/types.js';
+import type * as AST from '../../parser/ast.js';
+import type { RelationalPlanNode } from '../../planner/nodes/plan-node.js';
+import type { ColumnSchema } from '../../schema/column.js';
+import { type TableSchema } from '../../schema/table.js';
+import type { CoarsenedKeyInfo } from '../../schema/view.js';
+import { computeBodyHash } from '../../schema/view.js';
+import { type MaintainedTableSchema } from '../../schema/derivation.js';
+import type { Schema } from '../../schema/schema.js';
+import type { ResolveColumnInSource } from '../../schema/rename-rewriter.js';
+import type { BackingHost } from '../../vtab/backing-host.js';
+export { computeBodyHash };
+/**
+ * Purpose-built diagnostic for a bag (duplicate-producing) materialized-view
+ * body. A v1 materialized view is a *keyed* derived relation: its body must
+ * produce a **set** (no duplicate rows under the backing-table key). This
+ * replaces the raw `UNIQUE constraint failed: <backing table> PK` message —
+ * which named a hidden implementation detail — with one that names the MV and
+ * explains the contract. Raised at create (loud, immediate) or at the next
+ * refresh if a duplicate-free body later becomes duplicate-producing.
+ */
+export declare function materializedViewNotASetError(schemaName: string, viewName: string): QuereusError;
+/** Backing-table column/PK/ordering shape derived from the optimized body relation. */
+export interface BackingShape {
+    columns: ColumnSchema[];
+    primaryKey: ReadonlyArray<{
+        index: number;
+        desc: boolean;
+    }>;
+    ordering?: ReadonlyArray<{
+        index: number;
+        desc: boolean;
+    }>;
+    /** Qualified (lowercased `schema.table`) source tables the body reads. */
+    sourceTables: string[];
+    /** Present when `primaryKey` is a **collation-coarsened lineage key** — the body
+     *  has no provable key and the backing identity was derived from source-key
+     *  lineage with at least one collation-weakened column (the parallel-migration
+     *  shape — `deriveCoarsenedBackingKey`). Drives the create-time key-coarsening
+     *  warning and the MV-record stamp. Absent when `keysOf` proved a key, when the
+     *  lineage key does not coarsen, or when no key was derivable at all (the
+     *  all-columns fallback; such a body is rejected at registration). */
+    coarsenedKey?: CoarsenedKeyInfo;
+    /** All minimal candidate keys proved by `keysOf` for the body root, as sorted
+     *  column-index arrays. Present only when `keysOf` returned at least one key
+     *  (i.e., not the coarsened-lineage or all-columns path). Used by
+     *  `tryRecompileMaterializedViewLive` to check if the existing backing PK is
+     *  still a superkey after a body-irrelevant constraint change. */
+    allProvedKeys?: ReadonlyArray<ReadonlyArray<number>>;
+}
+/**
+ * Builds + optimizes the materialized-view body and derives the backing table's
+ * column list, primary key, body ordering, and source-table dependencies.
+ *
+ * Columns and types come straight from the optimized relation's
+ * {@link RelationalPlanNode.getType}; the PK is the first usable key from
+ * `keysOf` (all-columns fallback when none — such an MV is incremental-ineligible
+ * until Phase 2). Re-planning here is cheap relative to materialization and keeps
+ * the create/refresh emitters free of optimizer plumbing.
+ */
+export declare function deriveBackingShape(db: Database, bodySql: string, explicitColumns: ReadonlyArray<string> | undefined): BackingShape;
+/**
+ * Computes the backing table's *physical* primary key. When the body carries an
+ * `order by`, the ordering columns lead the key so the btree clusters (and scans)
+ * in the body's order — "seeding the backing-table ordering" — with the logical
+ * key (from `keysOf`) appended as a uniqueness-preserving tiebreaker. Without an
+ * `order by`, the physical key is just the logical key.
+ *
+ * NOTE: this diverges from `TableDerivation.logicalKey`, which keeps the
+ * logical `keysOf` identity. The covering ticket replaces this seeding with a
+ * proper materialized index.
+ */
+export declare function computeBackingPrimaryKey(shape: BackingShape): ReadonlyArray<{
+    index: number;
+    desc: boolean;
+}>;
+/**
+ * Constructs the backing-table {@link TableSchema} for a materialized view from a
+ * derived {@link BackingShape}, hosted in `moduleName` (default `'memory'`).
+ * The capability check here is defense-in-depth — the create builder already
+ * gates, but the catalog-import path reaches this without it.
+ */
+export declare function buildBackingTableSchema(db: Database, schemaName: string, backingTableName: string, shape: BackingShape, moduleName?: string, moduleArgs?: Readonly<Record<string, SqlValue>>, 
+/** Table-level metadata tags (the MV's `with tags (…)` — top-level on the unified record). */
+tags?: Readonly<Record<string, SqlValue>>): TableSchema;
+/** Runs the body to completion and returns its rows (raw `Row` arrays). Uses the
+ *  no-transaction-management primitive — the caller is already inside DDL execution. */
+export declare function collectBodyRows(db: Database, bodySql: string): Promise<Row[]>;
+/**
+ * Everything needed to materialize an MV — identity, canonical DDL, and the body
+ * in both AST and canonical-SQL form. Satisfied by the create plan node
+ * (`CreateMaterializedViewNode`) and by a re-parsed catalog entry
+ * (`SchemaManager.importMaterializedView`).
+ */
+export interface MaterializeViewDefinition {
+    schemaName: string;
+    viewName: string;
+    /** Body AST — retained on the derivation for refresh, declarative emission, and body-hash. */
+    selectAst: AST.QueryExpr;
+    /** Canonical SQL of the body alone (re-planned here to derive and fill the backing). */
+    bodySql: string;
+    /** Explicit column list from `create materialized view mv(a, b) ...`, when present. */
+    columns?: ReadonlyArray<string>;
+    tags?: Readonly<Record<string, SqlValue>>;
+    /** Normalized backing-host module (absent ⇒ memory default — see
+     *  `normalizeBackingModule` in schema/view.ts). */
+    backingModuleName?: string;
+    /** Backing-module args; recorded only when non-empty. */
+    backingModuleArgs?: Readonly<Record<string, SqlValue>>;
+}
+/**
+ * Throws the sited declared-column-arity diagnostic when `def`'s explicit column
+ * list disagrees with the body's output arity. Build-time creation already
+ * validated this (with a build-located diagnostic); this guards the import path —
+ * both the refill arm ({@link materializeView}) and the adopt gate check
+ * (`SchemaManager.tryAdoptPreExistingBacking`, which must raise it BEFORE the
+ * caller drops a durable backing: the entry can never materialize, so dropping
+ * would destroy rows for nothing). The refresh path deliberately does NOT share
+ * this — it reaches a legitimate mismatch after a source ALTER and has its own
+ * "drop and recreate" diagnostic.
+ */
+export declare function assertDeclaredColumnArity(def: MaterializeViewDefinition, shape: BackingShape): void;
+/**
+ * The materialize core shared by `emitCreateMaterializedView` and the
+ * catalog-import path (`SchemaManager.importMaterializedView`): derive the
+ * backing shape from the planned body → create the maintained table under the
+ * MV's own name in the declared backing-host module (memory default) → fill it
+ * from the body → attach the {@link TableDerivation} → compile + register
+ * row-time write-through maintenance. Returns the registered maintained table.
+ *
+ * Fires `table_added` for the table (it is created like any table) but
+ * deliberately does NOT fire `materialized_view_added` — the create emitter
+ * notifies after this returns, while import stays silent (a store rehydrating
+ * its own catalog must not re-emit persistence events).
+ *
+ * Rollback-on-throw: a fill failure (including the "must be a set"
+ * duplicate-key gate) drops the half-built table; a registration failure (the
+ * mandatory row-time eligibility gate runs there) drops the table — derivation
+ * and all — either way the schema is left exactly as before the call.
+ * Existence/collision checks are the caller's job (the create emitter checks
+ * before calling; on import a duplicate surfaces as a table-name conflict).
+ *
+ * `preDerivedShape` short-circuits the shape derivation for a caller that
+ * already planned the body (the import path derives it once for its gates).
+ */
+export declare function materializeView(db: Database, def: MaterializeViewDefinition, preDerivedShape?: BackingShape): Promise<MaintainedTableSchema>;
+/**
+ * The adopt-without-refill counterpart of {@link materializeView}: the
+ * registration tail without create+fill, for the catalog-import path
+ * (`SchemaManager.importMaterializedView`) when a pre-existing durable backing
+ * passed every adopt gate (same module, shape match, all sources same-module
+ * with upstream maintained tables themselves adopted, caller-attested
+ * `trustBackings`). The table's rows are trusted as-is — no body execution.
+ *
+ * **Backing schema re-stamp.** `preExisting` is a phase-1 DDL round-trip and
+ * loses ScalarType fidelity the refill path would carry (the registry-interned
+ * logical types survive only by name in DDL). Re-registering the body-derived
+ * {@link buildBackingTableSchema} result — shape-verified identical by the
+ * caller's `backingShapeMatches` gate — makes post-adopt state equivalent to
+ * post-refill state for the row-time plan `registerMaterializedView` binds.
+ * Module identity/args come from `def` exactly as the refill path's
+ * `buildBackingTableSchema` call does (gate 1 verified the registered module
+ * matches); `estimatedRows` carries over from the registered schema (the rows
+ * are preserved, so the prior estimate stays truthful). The module-side LIVE
+ * table instance still caches the phase-1 schema — the importing host
+ * reconciles it after import (the store module's `rehydrateCatalog` runs
+ * `StoreTable.updateSchema` over every connected table); reads are unaffected
+ * either way since the shapes are identical.
+ *
+ * Rollback on a registration failure (the mandatory row-time eligibility gate
+ * runs there): unlink + detach the derivation + rethrow — the table stays
+ * REGISTERED, reverting to its plain (derivation-less) state. Dropping a
+ * durable backing on a registration error would destroy the very rows a later
+ * retry could adopt; the caller records the throw as a per-entry rehydration
+ * error.
+ */
+export declare function adoptMaterializedView(db: Database, def: MaterializeViewDefinition, preExisting: TableSchema, shape: BackingShape): Promise<MaintainedTableSchema>;
+/**
+ * The attach core shared by `alter table … set maintained as` (fresh attach and
+ * re-attach) and `create table … maintained as` (attach-to-empty, via
+ * {@link createMaintainedTable}): verify-by-diff, never trust, never refill
+ * wholesale.
+ *
+ * Sequence — every gate runs BEFORE any catalog or data mutation:
+ *  1. backing-host capability (defense-in-depth; the builders gate with a sited
+ *     error);
+ *  2. derive the body's shape (rewrite-suppressed) and run the STRICT
+ *     declared-shape check ({@link describeAttachShapeMismatch} — names
+ *     included);
+ *  3. cycle / self-reference check over the live derivation graph;
+ *  4. evaluate the body once and reject duplicate derived keys (the loud
+ *     "must be a set" reject);
+ *  5. catalog flip (`attachDerivation`) + maintenance registration — the
+ *     create-time gates (determinism, keyed-or-coarsened body, full-rebuild
+ *     size threshold) run inside `registerMaterializedView`, before any row is
+ *     written; a throw restores the prior record (and the prior plan, on
+ *     re-attach);
+ *  6. reconcile-by-diff: one `'replace-all'` op against the table's effective
+ *     contents through the backing host — collation-aware pairing,
+ *     byte-faithful identical-row skip, so identical content writes nothing and
+ *     divergence resolves derived-wins with the minimal genuine
+ *     {@link BackingRowChange}s. The writes land in the connection's PENDING
+ *     state, committing/rolling back in lockstep with the statement;
+ *  7. covering links (clear the prior body's, stamp the new body's), cascade
+ *     the genuine changes to consumer maintained tables, fire
+ *     `materialized_view_added` (fresh) / `materialized_view_modified`
+ *     (re-attach) so store catalogs re-persist the canonical table-form DDL,
+ *     and surface the key-coarsening warning exactly as create does.
+ *
+ * `recordedColumns` is recorded verbatim as `derivation.columns` (the lossless
+ * implicit/explicit signal the persist + import paths already use): the authored
+ * column names for the explicit forms — `create table … maintained (columns) as`
+ * AND the re-attach verb `set maintained (columns) as` — or `undefined` for the
+ * implicit forms — `create table … maintained as` (which reshapes its source on
+ * reopen) AND the implicit re-attach verb `set maintained as` (which reshapes to
+ * follow the body's natural names). When `positionalRename` is set — every
+ * explicit form — the body outputs are renamed positionally to `recordedColumns`
+ * and the per-column name check is skipped (the authored list is the authoritative
+ * output-name vector); otherwise the strict declared-shape check (names included)
+ * applies. `buildTableDerivation` hashes `recordedColumns` into `bodyHash`, so
+ * live exec and catalog import of the same canonical DDL agree on both the record
+ * and the hash — making attach/create → persist → reopen a fixed point.
+ *
+ * An explicit list whose arity disagrees with the body raises a sited error (the
+ * list-vs-body arity guard) before anything is recorded — `deriveBackingShape`
+ * sizes the shape to the body, so a surplus/short list would otherwise persist a
+ * miscounted `derivation.columns`.
+ *
+ * **Reshape-on-attach (`allowReshape`).** The verb path (`set maintained [(cols)]
+ * as` — manual AND differ-emitted) passes `allowReshape = true`; create and any
+ * non-verb caller pass `false` and keep the strict declared-shape error. Two
+ * reshape triggers, both reusing the two-phase splice + restore handlers below:
+ *
+ *  - **Implicit call** (no rename list): on a strict-shape mismatch the backing
+ *    reshapes in place to follow the body's natural names — the same "the body
+ *    owns an implicit table's shape" contract the refresh reshape and the implicit
+ *    table form's reopen honor. Now permitted over a prior-EXPLICIT record too:
+ *    `set maintained as <body>` over an `(a, b)` table abandons the authored list
+ *    and relabels the backing to the body's names, recording an implicit
+ *    derivation (the deliberate "go implicit" re-attach).
+ *  - **Explicit call** (`positionalRename`): a same-arity output-NAME drift
+ *    `(a, b) → (a, c)` produces no strict mismatch (names are skipped), yet the
+ *    backing must be relabeled to the recorded names — classified as a reshape.
+ *    The derived shape carries the TARGET names, so {@link classifyBackingReshape}
+ *    emits a pure positional RENAME (`b → c`); a renamed PK output column is
+ *    matched through the rename map (not a key change). A count/type/PK delta is
+ *    still the strict error, and a reorder/swap (`(a, b) → (b, a)`) classifies as
+ *    inexpressible.
+ *
+ * An inexpressible delta (interleave / physical-PK change, or a host module
+ * without `alterTable`) raises {@link inexpressibleReshapeError} with the table
+ * untouched. An expressible plan splices around the verify-by-diff reconcile —
+ * see the sequencing notes inside.
+ */
+export declare function attachMaintainedDerivation(db: Database, table: TableSchema, select: AST.QueryExpr, recordedColumns: ReadonlyArray<string> | undefined, positionalRename?: boolean, allowReshape?: boolean, 
+/**
+ * When true, a FAILED FRESH attach discards (via {@link VirtualTableModule.discardBackingForAttach})
+ * any backing store {@link VirtualTableModule.ensureBackingForAttach} created IN
+ * THIS attach. Set by the `set maintained` ATTACH verb ({@link runSetMaintained}),
+ * which owns its own backing cleanup. NOT set by `create table … maintained`
+ * ({@link createMaintainedTable}) — there the store was created by the prior
+ * `createTable(preferBacking)`, and the create path's own `dropTable` cleanup
+ * retires it; a discard here would double-drop and strand the catalog entry.
+ */
+discardBackingOnFailure?: boolean): Promise<MaintainedTableSchema>;
+/**
+ * Detach a maintained table's derivation — `alter table … drop maintained`.
+ * Catalog-only: nothing physical changes. The row-time plan is released, the
+ * covering-structure link un-stamped (UNIQUE enforcement falls back to the
+ * auto-index), and the registered record swapped for the same table minus the
+ * derivation — rows, indexes, module identity, and tags all stay; staleness
+ * state lives on the derivation and leaves with it. The table becomes ordinary
+ * and user-writable.
+ *
+ * Fires `materialized_view_removed` ONLY: the maintenance manager releases any
+ * remaining plan, store catalogs delete the persisted maintained entry (a
+ * store-hosted table's plain bundle is already clause-free), and cached
+ * statement plans over the table invalidate (a cached write-through plan
+ * compiled against the old derivation must not survive the flip). Deliberately
+ * NO `table_modified`: the table's shape and rows are unchanged, so consumer
+ * maintained tables reading it stay live — subsequent user writes drive their
+ * maintenance exactly like any source write.
+ */
+export declare function detachMaintainedDerivation(db: Database, mv: MaintainedTableSchema): TableSchema;
+/**
+ * `create table … maintained as <body>` — the declared-shape authoring form,
+ * executed all-or-nothing:
+ *
+ *  - an existing table/view + `if not exists` skips ENTIRELY (never a
+ *    half-attach); without it, the standard already-exists error — both before
+ *    the body is planned;
+ *  - the declared shape is verified against the derived body shape BEFORE any
+ *    catalog registration ({@link SchemaManager.buildDeclaredTableSchema} builds
+ *    the schema the CREATE would register, without registering it);
+ *  - then the table registers through the ordinary `createTable` path (declared
+ *    constraints and defaults intact) and the shared {@link attachMaintainedDerivation}
+ *    core runs — attach-to-empty: the reconcile diff against an empty table IS
+ *    the fill, applied to the connection's pending state so it commits in
+ *    lockstep with the statement (no `replaceContents` commit-first caveat);
+ *  - any failure past registration (duplicate derived keys, a maintenance gate)
+ *    drops the just-created table — the schema is left exactly as before.
+ *
+ * The attach core re-derives the body AFTER the table registers, so a body that
+ * resolves differently once the new name exists (e.g. a same-name reference that
+ * becomes a self-reference) is caught by the cycle check and rolled back.
+ */
+export declare function createMaintainedTable(db: Database, stmt: AST.CreateTableStmt): Promise<MaintainedTableSchema | undefined>;
+/**
+ * Full-rebuild of a maintained table's contents: re-run the body to completion
+ * and swap the table to the recomputed set. The always-correct path the two
+ * `refresh materialized view` arms funnel through — the fast (data-only) path
+ * (`backingShapeMatches` ⇒ direct `rebuildBacking`) and the reshape arm
+ * (`reshapeBackingInPlace`, between its pre- and post-reconcile structural ops).
+ * It is used by NOTHING else: create/import (`materializeView`) calls
+ * `replaceContents` directly, and the incremental manager's full-rebuild arm
+ * (`applyFullRebuild` in `core/database-materialized-views.ts`) does its own
+ * `applyMaintenance` + per-delta validation (`validateDerivedChanges`).
+ *
+ * **Constraint-bearing branch.** When the maintained table declares ≥1 applicable
+ * CHECK or (FK-enforcement-on) child-side FK ({@link hasApplicableConstraints}),
+ * the swap mirrors the attach core instead of calling `replaceContents`: reject
+ * duplicate derived keys ({@link assertRefreshRowsAreSet} — parity with
+ * `replaceContents`'s set gate), land the recomputed set in the connection's
+ * PENDING layer via `applyMaintenance('replace-all')`, run the eager bulk
+ * anti-join / `not (<check>)` scan ({@link validateDeclaredConstraintsOverContents})
+ * which throws the maintained-table-attributed CONSTRAINT diagnostic on the first
+ * violator BEFORE the swap is committed (the failing statement unwinds and the
+ * pending reconcile is discarded by statement-level rollback — the pre-refresh
+ * COMMITTED contents stay intact), then `conn.commit()`.
+ *
+ * The commit is **commit-first parity** and load-bearing two ways: (1)
+ * `replaceContents` already swaps committed state (a `begin; refresh; rollback`
+ * does NOT undo a refresh today), so committing here preserves that exact
+ * observable behavior; (2) on the reshape arm, `reshapeBackingInPlace`'s
+ * post-reconcile data-validating ops (retype/recollate/tighten-NOT-NULL) scan
+ * COMMITTED contents after this returns, so they must see the rebuilt rows —
+ * `replaceContents` gives that implicitly, the pending-layer branch matches it by
+ * committing (as the attach reshape path does before its own post-reconcile ops).
+ *
+ * The real-world trigger is a STALE table: a body-relevant source change released
+ * the MV's row-time plan, subsequent source writes drifted unvalidated, and a
+ * refresh recomputes that drifted set — so this scan is where a declared CHECK/FK
+ * is enforced over rows that never crossed the maintenance boundary. A
+ * continuously-maintained table re-derives an already-validated set, so the scan
+ * is redundant-but-cheap there.
+ *
+ * Constraint-less maintained tables and every MV-sugar backing take the untouched
+ * `replaceContents` fast path — no connection, no scan, byte-for-byte the prior
+ * behavior. The caller is responsible for staleness re-validation when relevant;
+ * this helper assumes the derivation body plans. Throws if the table is missing
+ * from the catalog.
+ */
+export declare function rebuildBacking(db: Database, mv: MaintainedTableSchema): Promise<void>;
+/**
+ * True iff the live backing `TableSchema` is structurally identical to what the
+ * derived `shape` would build — so a `refresh` can take the data-only fast path
+ * (`rebuildBacking`, preserving the backing identity and warm caches) instead of
+ * rebuilding the backing table. Compares, in order:
+ *  - column **count**;
+ *  - per column: **name** (case-insensitive — matching the matcher's name compare),
+ *    **logical type**, **not-null**, **collation**;
+ *  - the **physical** PK ({@link computeBackingPrimaryKey} vs the backing's
+ *    `primaryKeyDefinition`, by index + desc + collation, in order).
+ *
+ * Returns false when a source schema change has shifted the body's output shape
+ * (most visibly a `select *` body whose new source column interleaves into the
+ * output) — the caller then rebuilds the backing to match the re-planned body.
+ */
+export declare function backingShapeMatches(current: TableSchema, shape: BackingShape): boolean;
+/**
+ * True when a `table_modified` event's old→new transition is **body-irrelevant**:
+ * same table name and schema, columns pairwise identical in every body-relevant
+ * field ({@link bodyRelevantColumnMatches}), and an identical physical primary
+ * key. Everything else may differ — `checkConstraints`, `foreignKeys`,
+ * `uniqueConstraints`, `indexes`, `statistics`, `estimatedRows`, `tags`,
+ * `primaryKeyDefaultConflict`, defaults. A qualifying event cannot change what a
+ * dependent body evaluates to, only what it compiles to — see the section note
+ * above for why dependents are recompiled rather than skipped.
+ *
+ * **Reference-equality guard (load-bearing coupling).** The MV manager's
+ * `emitBackingInvalidation` fires a synthetic `table_modified` on an MV's own
+ * backing with the SAME object as `oldObject` and `newObject` — the event that
+ * cascades staleness down MV-over-MV chains. It must classify as body-RELEVANT,
+ * hence `oldObject === newObject` short-circuits to false here. Every genuine
+ * emitter passes distinct old/new objects. If either side changes, change both
+ * (see the matching comment in `emitBackingInvalidation`,
+ * core/database-materialized-views.ts).
+ */
+export declare function isBodyIrrelevantTableChange(oldObject: TableSchema, newObject: TableSchema): boolean;
+/**
+ * The set of source-column indices (in `qualifiedSource`'s POST-ALTER schema) that a
+ * materialized-view body **reads** — directly, through a predicate / join / group /
+ * order position, or transitively through a generated column. The disjointness half
+ * of the structural-ALTER content-stability gate (see the section note and
+ * {@link tryRecompileMaterializedViewLive}): a value-semantics change (type /
+ * collation) to a column NOT in this set cannot alter what the body evaluates to.
+ *
+ * **Why the un-optimized built plan, not `db.getPlan`.** The optimizer can absorb a
+ * `where v = 'x'` predicate into an access-method seek key, dropping the explicit
+ * {@link ColumnReferenceNode} from the tree — walking the optimized plan would MISS
+ * that reference and falsely conclude disjoint (UNSOUND). The un-optimized built plan
+ * (`db._buildPlan`) carries every reference explicitly in its projection / filter /
+ * join / group / order nodes. Over-approximation is the safe direction: an extra
+ * column in the read set only ever causes MORE staleness, never an unsound keep-live.
+ *
+ * Mechanics: walk the built tree (children AND relations, like {@link collectSourceTables},
+ * so nested subqueries / EXISTS / correlated refs are reached) collecting every
+ * `ColumnReferenceNode.attributeId`; for every `TableReferenceNode` whose qualified
+ * name equals `qualifiedSource` (several for a self-join) map the collected attribute
+ * ids back to its column indices via `getAttributes()`; union over occurrences. Then
+ * expand the set DOWNWARD through `generatedColumnDependencies` to a fixed point —
+ * reading a generated column reads its dependency columns even when the body never
+ * names them (safe whether or not the planner inlines generated columns: if it does,
+ * the dep already appears as a direct reference and the closure is a no-op; if it
+ * does not, the closure is load-bearing).
+ *
+ * The rewrite is suppressed for the same reason {@link deriveBackingShape} suppresses
+ * it. Any exception propagates to {@link tryRecompileMaterializedViewLive}'s try/catch,
+ * which treats a failed analysis as "could not prove disjoint" ⇒ stale (the safe
+ * default) — it must never be swallowed into a false "disjoint" conclusion.
+ */
+export declare function referencedSourceColumns(db: Database, bodySql: string, qualifiedSource: string): Set<number>;
+/**
+ * Recompile a LIVE materialized view's row-time plan in place after a **genuine**
+ * source `table_modified` (`oldObject !== newObject` — constraint/stats/tags-only OR
+ * structural ADD/DROP/ALTER COLUMN), gated by shape re-derivation and — for a
+ * structural value-semantics change — a content-stability proof. The same discipline
+ * as {@link restoreUnaffectedMaterializedViews}. Fully synchronous (the schema-change
+ * listener is sync; shape derivation, schema lookups, the disjointness analysis, and
+ * registration all are). Never throws: logs and returns `false` on any failure, and
+ * the caller falls back to the mark-stale path. On success the MV stays live —
+ * `stale` untouched, row-time plan rebuilt against the new catalog, no backing
+ * invalidation (the backing stays maintained, so cached plans reading it remain
+ * correct).
+ *
+ * **Structural-ALTER soundness (why a recompile is not enough on its own).** For a
+ * constraint-only change, re-derived backing-shape identity IMPLIES content identity —
+ * a constraint cannot change what stored rows the body evaluates to, only what the
+ * body compiles to. For a structural ALTER that argument does NOT carry: shape
+ * identity ⇏ content identity. `alter column v set collate nocase` / `set data type`
+ * on a column the body reads only in a WHERE / join / group / order position leaves
+ * the output shape identical while changing the admitted row set — the backing content
+ * diverges from a fresh body evaluation. So the structural keep-live adds a final
+ * **content-stability gate** proving the change's value-semantics-changed columns are
+ * disjoint from everything the body reads (the {@link valueSemanticsChangedColumns} ∩
+ * {@link referencedSourceColumns} proof). That changed set is EMPTY for constraint-only,
+ * ADD, DROP, NOT NULL, and DEFAULT changes, so the proof is a no-op there and preserves
+ * today's behavior exactly; it does real work only for ALTER COLUMN type/collation.
+ *
+ * Gates, in order — each failure is a stale fallback:
+ *  1. `deriveBackingShape` throws when the body no longer plans against the
+ *     post-change catalog (e.g. a rename-cascade constraint rewrite observed
+ *     mid-statement, while a co-source's rename has landed but this MV's body
+ *     rewrite has not — the rename propagation's own MV loop restores it later).
+ *     A DROP COLUMN the body references directly throws here too.
+ *  2. `sameSourceTables`: the re-planned source set must equal the recorded one.
+ *     An FK drop can un-eliminate a previously FK/PK-eliminated join (growing
+ *     the set); a constraint change can let `ruleFilterContradiction` fold a
+ *     source out of the plan entirely (shrinking it). Either way the record is
+ *     out of sync with the body's plan — leave it to REFRESH, which re-derives.
+ *  3. `backingColumnsStructurallyMatch` + `isBackingPkASuperkeyInShape`: the column
+ *     structural attributes (type / not-null / collation) must match positionally,
+ *     AND the live backing's physical PK column set must be a superkey of the
+ *     re-planned body (some proved minimal key ⊆ backing PK columns). This forces
+ *     staleness when a dropped UNIQUE un-proves the recorded backing key (`keysOf`
+ *     falls back to a smaller key or all-columns → no proved key ⊆ old PK). An
+ *     ADD CONSTRAINT UNIQUE that subsumes the compound key passes: the new minimal
+ *     key is a subset of the old compound backing PK. A `select *` body over an
+ *     ADD/DROP COLUMN reshapes its output here ⇒ shape mismatch ⇒ stale. A PROJECTED
+ *     column whose type/collation changed shifts the output column ⇒ shape mismatch
+ *     ⇒ stale. Re-registers with the EXISTING backing (PK unchanged) on a pass.
+ *  4. Content-stability gate (structural value-semantics ALTER only — see above):
+ *     if any value-semantics-changed column (type/collation) is read by the body
+ *     (transitively through generated columns), the backing content is unstable ⇒
+ *     stale. Empty changed set ⇒ no-op. A failure to build the disjointness analysis
+ *     propagates to the outer try/catch ⇒ stale (could not prove disjoint).
+ *  5. `registerMaterializedView` re-runs arm selection / eligibility / cost
+ *     gating (`buildMaintenancePlan`) against the new catalog and throws on the
+ *     create-time gates (non-determinism, bag/no-key floor, full-rebuild
+ *     pathology against fresh ANALYZE stats — defensible: the alternative is
+ *     unbounded per-write rebuild cost). Registration is event-silent, so the
+ *     success path fires no nested schema-change notifications.
+ *
+ * `oldObject`/`newObject` are the genuine event's distinct schemas. The synthetic
+ * backing-invalidation event (same object as old/new) is excluded by the caller's
+ * `oldObject !== newObject` guard — it must cascade staleness, never recompile.
+ *
+ * Deliberately NOT {@link restoreMaterializedViewLive}: that path is async, may
+ * rename backing columns, and clears `stale` — the wrong discipline here, where
+ * the MV is live throughout and a pre-existing `stale` flag must stay untouched.
+ */
+export declare function tryRecompileMaterializedViewLive(db: Database, mv: MaintainedTableSchema, oldObject: TableSchema, newObject: TableSchema): boolean;
+/**
+ * Identity-preserving reshape of a maintained table whose re-derived body shape
+ * shifted — the refresh path's replacement for the former drop+recreate. Classify
+ * the column delta; an inexpressible delta (interleave / PK-definition change)
+ * raises the sited error with the table untouched, an expressible one reshapes in
+ * place. The shape-match fast path (`backingShapeMatches` ⇒ data-only
+ * `rebuildBacking`) is the caller's and is untouched.
+ */
+export declare function reshapeBacking(db: Database, mv: MaintainedTableSchema, shape: BackingShape): Promise<MaintainedTableSchema>;
+/**
+ * Resolves the {@link BackingHost} for a materialized view's backing table via
+ * the owning module's backing-host capability (`vtab/backing-host.ts`). INTERNAL
+ * when the module lacks the capability or does not know the table — a backing
+ * table is engine-created on a capability-checked module, so either is a bug.
+ */
+export declare function resolveBackingHost(db: Database, backingSchema: TableSchema): BackingHost;
+/**
+ * Lenient counterpart of {@link resolveBackingHost}: returns the backing host, or
+ * `undefined` when the owning module cannot (yet) resolve one — instead of
+ * throwing. Used at maintenance-PLAN-BUILD time (the create-time gate registration),
+ * where the only use of the host is the host-conditional, default-inert
+ * `requiresReplicableDerivations` gate. A module that materializes its durable
+ * backing LATE in the attach flow (e.g. lamina's `ensureBackingForAttach`, which
+ * runs after the gate registration) has no host yet at plan-build time; the host is
+ * resolved for real at the reconcile, and the steady-state maintenance arms
+ * re-resolve it per use. Skipping the replicable gate when the host is absent is
+ * sound: a host that sets `requiresReplicableDerivations` (the synced-store flavor)
+ * always exists by plan-build time, so the gate still binds it — the
+ * eager-resolution invariant on {@link BackingHost.requiresReplicableDerivations}.
+ *
+ * That soundness rests on the invariant being honored, not on prose: a host that
+ * BOTH demands replicable derivations AND defers its host to the late seam would
+ * skip the gate here unnoticed. The attach core's defensive guard
+ * ({@link attachMaintainedDerivation}) re-checks once the late host is in hand and
+ * raises a loud INTERNAL error in exactly that case, so this lenient skip can never
+ * silently let a non-replicable body through.
+ */
+export declare function tryResolveBackingHost(db: Database, backingSchema: TableSchema): BackingHost | undefined;
+/**
+ * Eagerly records the constraint↔structure link when this MV covers a UNIQUE
+ * constraint on one of its single source tables. Runs the coverage prover
+ * (`coverage-prover.ts`) over the optimized body and, on the first match, stamps
+ * the MV's `origin`/`covers` reverse link and the constraint's
+ * `coveringStructureName` forward pointer (the source of truth). Informational
+ * in this ticket — nothing enforces through the MV's backing table yet.
+ *
+ * Best-effort and side-effect-bounded: the body has already planned (during
+ * shape derivation), so re-planning here is cheap and safe; a non-covering MV
+ * simply records nothing.
+ */
+export declare function linkCoveredUniqueConstraints(db: Database, mv: MaintainedTableSchema, bodySql: string): void;
+/**
+ * Clears the constraint↔structure link a covering MV established (drop path).
+ * Matches on the forward pointer (`coveringStructureName === mv.name`) so it
+ * works for unnamed constraints too; no enforcement demotion — physical schemas
+ * still enforce via the implicit auto-index.
+ */
+export declare function unlinkCoveredUniqueConstraints(db: Database, mv: MaintainedTableSchema): void;
+/** Re-validates a stale MV's body against the current source schemas. Throws the
+ *  staleness diagnostic when the body no longer plans. Returns the optimized
+ *  relational root on success. */
+export declare function revalidateBody(db: Database, mvName: string, bodySql: string): RelationalPlanNode;
+/**
+ * Lowercased `schema.name` keys of every MV that is stale *right now*. The rename
+ * emitters snapshot this BEFORE the statement's first schema-change notify, so the
+ * propagation pass can distinguish "stale from this very rename statement" (safe to
+ * clear after a successful in-place rewrite — no DML can interleave within the
+ * statement) from "stale from an earlier un-refreshed change" (the backing may
+ * already be behind — writes during staleness are not maintained — so only a
+ * successful REFRESH may clear it).
+ */
+export declare function snapshotStaleMaterializedViews(db: Database): ReadonlySet<string>;
+/**
+ * Rewrites every dependent materialized view in `schema` after a source TABLE
+ * RENAME — the MV mirror of the plain-view loop in `propagateTableRenameInSchema`
+ * ("MV ≡ faster view"): the caller applies the same same-schema gate, and the body
+ * `selectAst` is mutated in place by the same `renameTableInAst` walker. An MV is
+ * processed when its body AST changed, its `insert defaults` clause changed (an
+ * expr subquery can name the renamed table even when the body doesn't), OR its
+ * `sourceTables` carries the old base — the latter catches a body that reads the
+ * renamed table *through a plain view* (the view's AST was rewritten by the view
+ * loop, but this MV's own AST never names the table while its row-time plan is
+ * still keyed under the old base).
+ *
+ * Per processed MV the derived fields are recomputed on a shallow clone
+ * (`sourceTables` re-keyed old→new, `bodyHash`, regenerated `sql`, the `covers`
+ * reverse link), then {@link applyMaterializedViewRewrite} re-registers row-time
+ * maintenance / preserves pre-existing staleness and fires
+ * `materialized_view_modified`. Failures mark the MV stale and propagation
+ * continues — best-effort, like the rest of the rename propagation.
+ */
+export declare function propagateTableRenameToMaterializedViews(db: Database, schema: Schema, renamedSchemaName: string, oldName: string, newName: string, preStale: ReadonlySet<string>): Promise<void>;
+/**
+ * Rewrites every dependent materialized view in `schema` after a source COLUMN
+ * RENAME — the MV mirror of the plain-view loop in `propagateColumnRenameInSchema`
+ * (same same-schema gate at the caller, same in-place `renameColumnInAst` walk).
+ * The body walk also descends the trailing `with defaults (…)` clause (now on
+ * `selectAst.defaults`): the clause target is typically a projected-away NOT NULL
+ * column the body never mentions, so its rewrite still flips `bodyChanged` and
+ * forces the re-hash / regenerate-DDL / fire-event path. An MV the walk does not
+ * touch that the schema-change listener marked stale (an unreferenced-column
+ * rename, a `select *` body) is restored by the
+ * {@link restoreUnaffectedMaterializedViews} pass the ALTER emitter runs after
+ * all per-schema loops. A changed BODY can shift the MV's *exposed output names*
+ * (a bare passthrough projection of the renamed column — plain-view parity),
+ * which {@link applyMaterializedViewRewrite} carries onto the live backing table.
+ */
+export declare function propagateColumnRenameToMaterializedViews(db: Database, schema: Schema, renamedSchemaName: string, tableName: string, oldCol: string, newCol: string, preStale: ReadonlySet<string>, resolveColumnInSource: ResolveColumnInSource): Promise<void>;
+/**
+ * Restores every dependent MV that THIS rename statement marked stale but the
+ * rename provably did not affect. Runs once at the end of the table-/column-rename
+ * propagation, after all per-schema loops — so every body rewrite, backing-column
+ * rename, and cascade event has already fired and the catalog is fully renamed.
+ *
+ * The schema-change listener marks **every** MV whose `sourceTables` includes a
+ * `table_modified` table stale (and detaches its row-time plan), but the rename
+ * propagation only restores MVs it processes (changed AST / clause, or — table
+ * rename — `sourceTables` carrying the old base). An MV the rename does not touch
+ * fell through stale-but-valid: reads silently served the now-unmaintained backing
+ * and writes never propagated until a manual REFRESH. Three concrete shapes: a
+ * column rename the body never references; a rename whose only effect on another
+ * source is a constraint rewrite (e.g. an FK `references` target) firing that
+ * source's `table_modified`; and a `select *` body whose output is a pure name
+ * shift (the AST is unchanged, so the body rewrite never sees it).
+ *
+ * Per candidate (`stale` now, not stale at the pre-statement snapshot — a
+ * pre-existing flag means the backing may be BEHIND and only REFRESH may clear it):
+ * re-derive the backing shape from the body against the renamed catalog; a
+ * **structural** mismatch is not a rename no-op → leave stale (REFRESH's
+ * shape-mismatch rebuild owns it); otherwise run the shared restore tail —
+ * {@link renameShiftedBackingColumns} carries a pure name shift onto the live
+ * backing (no-op when names already match; its backing `table_modified`
+ * deliberately cascades staleness to chained MVs referencing the old output name),
+ * then re-register row-time maintenance and clear `stale`.
+ *
+ * Deliberately fires NO `materialized_view_modified`: the MV record (AST, hash,
+ * sql, sourceTables) is unchanged here — `stale` is runtime state, not persisted.
+ * Walks all schemas (the listener marks cross-schema dependents too), in creation
+ * order — topological for same-schema MV chains, so a producer restores before its
+ * consumer is examined. A chained MV whose body references a renamed-away producer
+ * output name fails shape derivation and stays stale (staleness-diagnostic parity
+ * with a broken plain-view chain). Best-effort like the rest of the propagation:
+ * a per-MV failure logs, leaves that MV stale, and continues.
+ */
+export declare function restoreUnaffectedMaterializedViews(db: Database, preStale: ReadonlySet<string>): Promise<void>;
+//# sourceMappingURL=materialized-view-helpers.d.ts.map

package/dist/src/runtime/emit/materialized-view-helpers.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"materialized-view-helpers.d.ts","sourceRoot":"","sources":["../../../../src/runtime/emit/materialized-view-helpers.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAAE,YAAY,EAAE,MAAM,wBAAwB,CAAC;AACtD,OAAO,EAAc,KAAK,GAAG,EAAE,KAAK,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAC5E,OAAO,KAAK,KAAK,GAAG,MAAM,qBAAqB,CAAC;AAEhD,OAAO,KAAK,EAAY,kBAAkB,EAAE,MAAM,kCAAkC,CAAC;AAMrF,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,wBAAwB,CAAC;AAC3D,OAAO,EAAE,KAAK,WAAW,EAAsF,MAAM,uBAAuB,CAAC;AAQ7I,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,sBAAsB,CAAC;AAC7D,OAAO,EAAE,eAAe,EAAE,MAAM,sBAAsB,CAAC;AACvD,OAAO,EAAqB,KAAK,qBAAqB,EAAwB,MAAM,4BAA4B,CAAC;AACjH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,wBAAwB,CAAC;AAErD,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,iCAAiC,CAAC;AAE7E,OAAO,KAAK,EAAE,WAAW,EAAoB,MAAM,4BAA4B,CAAC;AAWhF,OAAO,EAAE,eAAe,EAAE,CAAC;AAE3B;;;;;;;;GAQG;AACH,wBAAgB,4BAA4B,CAAC,UAAU,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,YAAY,CAS/F;AAED,uFAAuF;AACvF,MAAM,WAAW,YAAY;IAC5B,OAAO,EAAE,YAAY,EAAE,CAAC;IACxB,UAAU,EAAE,aAAa,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,OAAO,CAAA;KAAE,CAAC,CAAC;IAC5D,QAAQ,CAAC,EAAE,aAAa,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,OAAO,CAAA;KAAE,CAAC,CAAC;IAC3D,0EAA0E;IAC1E,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB;;;;;;0EAMsE;IACtE,YAAY,CAAC,EAAE,gBAAgB,CAAC;IAChC;;;;sEAIkE;IAClE,aAAa,CAAC,EAAE,aAAa,CAAC,aAAa,CAAC,MAAM,CAAC,CAAC,CAAC;CACrD;AAED;;;;;;;;;GASG;AACH,wBAAgB,kBAAkB,CACjC,EAAE,EAAE,QAAQ,EACZ,OAAO,EAAE,MAAM,EACf,eAAe,EAAE,aAAa,CAAC,MAAM,CAAC,GAAG,SAAS,GAChD,YAAY,CAMd;AA4HD;;;;;;;;;;GAUG;AACH,wBAAgB,wBAAwB,CAAC,KAAK,EAAE,YAAY,GAAG,aAAa,CAAC;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,OAAO,CAAA;CAAE,CAAC,CAa7G;AAED;;;;;GAKG;AACH,wBAAgB,uBAAuB,CACtC,EAAE,EAAE,QAAQ,EACZ,UAAU,EAAE,MAAM,EAClB,gBAAgB,EAAE,MAAM,EACxB,KAAK,EAAE,YAAY,EACnB,UAAU,CAAC,EAAE,MAAM,EACnB,UAAU,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC;AAC/C,8FAA8F;AAC9F,IAAI,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC,GACvC,WAAW,CAyCb;AAED;wFACwF;AACxF,wBAAsB,eAAe,CAAC,EAAE,EAAE,QAAQ,EAAE,OAAO,EAAE,MAAM,GAAG,OAAO,CAAC,GAAG,EAAE,CAAC,CAgBnF;AAED;;;;;GAKG;AACH,MAAM,WAAW,yBAAyB;IACzC,UAAU,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,8FAA8F;IAC9F,SAAS,EAAE,GAAG,CAAC,SAAS,CAAC;IACzB,wFAAwF;IACxF,OAAO,EAAE,MAAM,CAAC;IAChB,uFAAuF;IACvF,OAAO,CAAC,EAAE,aAAa,CAAC,MAAM,CAAC,CAAC;IAChC,IAAI,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC,CAAC;IAC1C;uDACmD;IACnD,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,yDAAyD;IACzD,iBAAiB,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC,CAAC;CACvD;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,yBAAyB,CAAC,GAAG,EAAE,yBAAyB,EAAE,KAAK,EAAE,YAAY,GAAG,IAAI,CAOnG;AAkED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAsB,eAAe,CAAC,EAAE,EAAE,QAAQ,EAAE,GAAG,EAAE,yBAAyB,EAAE,eAAe,CAAC,EAAE,YAAY,GAAG,OAAO,CAAC,qBAAqB,CAAC,CA4DlJ;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,wBAAsB,qBAAqB,CAC1C,EAAE,EAAE,QAAQ,EACZ,GAAG,EAAE,yBAAyB,EAC9B,WAAW,EAAE,WAAW,EACxB,KAAK,EAAE,YAAY,GACjB,OAAO,CAAC,qBAAqB,CAAC,CAuBhC;AAoRD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4EG;AACH,wBAAsB,0BAA0B,CAC/C,EAAE,EAAE,QAAQ,EACZ,KAAK,EAAE,WAAW,EAClB,MAAM,EAAE,GAAG,CAAC,SAAS,EACrB,eAAe,EAAE,aAAa,CAAC,MAAM,CAAC,GAAG,SAAS,EAClD,gBAAgB,UAAQ,EACxB,YAAY,UAAQ;AACpB;;;;;;;;GAQG;AACH,uBAAuB,UAAQ,GAC7B,OAAO,CAAC,qBAAqB,CAAC,CAiUhC;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,0BAA0B,CAAC,EAAE,EAAE,QAAQ,EAAE,EAAE,EAAE,qBAAqB,GAAG,WAAW,CAmB/F;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAsB,qBAAqB,CAAC,EAAE,EAAE,QAAQ,EAAE,IAAI,EAAE,GAAG,CAAC,eAAe,GAAG,OAAO,CAAC,qBAAqB,GAAG,SAAS,CAAC,CAwD/H;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,wBAAsB,cAAc,CAAC,EAAE,EAAE,QAAQ,EAAE,EAAE,EAAE,qBAAqB,GAAG,OAAO,CAAC,IAAI,CAAC,CA2D3F;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,mBAAmB,CAAC,OAAO,EAAE,WAAW,EAAE,KAAK,EAAE,YAAY,GAAG,OAAO,CAMtF;AAkID;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,2BAA2B,CAAC,SAAS,EAAE,WAAW,EAAE,SAAS,EAAE,WAAW,GAAG,OAAO,CASnG;AAkED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,wBAAgB,uBAAuB,CAAC,EAAE,EAAE,QAAQ,EAAE,OAAO,EAAE,MAAM,EAAE,eAAe,EAAE,MAAM,GAAG,GAAG,CAAC,MAAM,CAAC,CAqC3G;AAiBD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoEG;AACH,wBAAgB,gCAAgC,CAC/C,EAAE,EAAE,QAAQ,EACZ,EAAE,EAAE,qBAAqB,EACzB,SAAS,EAAE,WAAW,EACtB,SAAS,EAAE,WAAW,GACpB,OAAO,CAwET;AAkRD;;;;;;;GAOG;AACH,wBAAsB,cAAc,CACnC,EAAE,EAAE,QAAQ,EACZ,EAAE,EAAE,qBAAqB,EACzB,KAAK,EAAE,YAAY,GACjB,OAAO,CAAC,qBAAqB,CAAC,CAMhC;AA2HD;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAAC,EAAE,EAAE,QAAQ,EAAE,aAAa,EAAE,WAAW,GAAG,WAAW,CAiBxF;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAgB,qBAAqB,CAAC,EAAE,EAAE,QAAQ,EAAE,aAAa,EAAE,WAAW,GAAG,WAAW,GAAG,SAAS,CAGvG;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,4BAA4B,CAAC,EAAE,EAAE,QAAQ,EAAE,EAAE,EAAE,qBAAqB,EAAE,OAAO,EAAE,MAAM,GAAG,IAAI,CAwB3G;AAED;;;;;GAKG;AACH,wBAAgB,8BAA8B,CAAC,EAAE,EAAE,QAAQ,EAAE,EAAE,EAAE,qBAAqB,GAAG,IAAI,CAO5F;AAED;;kCAEkC;AAClC,wBAAgB,cAAc,CAAC,EAAE,EAAE,QAAQ,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,GAAG,kBAAkB,CAuBhG;AAID;;;;;;;;GAQG;AACH,wBAAgB,8BAA8B,CAAC,EAAE,EAAE,QAAQ,GAAG,WAAW,CAAC,MAAM,CAAC,CAMhF;AAYD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAsB,uCAAuC,CAC5D,EAAE,EAAE,QAAQ,EACZ,MAAM,EAAE,MAAM,EACd,iBAAiB,EAAE,MAAM,EACzB,OAAO,EAAE,MAAM,EACf,OAAO,EAAE,MAAM,EACf,QAAQ,EAAE,WAAW,CAAC,MAAM,CAAC,GAC3B,OAAO,CAAC,IAAI,CAAC,CAyBf;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAsB,wCAAwC,CAC7D,EAAE,EAAE,QAAQ,EACZ,MAAM,EAAE,MAAM,EACd,iBAAiB,EAAE,MAAM,EACzB,SAAS,EAAE,MAAM,EACjB,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,WAAW,CAAC,MAAM,CAAC,EAC7B,qBAAqB,EAAE,qBAAqB,GAC1C,OAAO,CAAC,IAAI,CAAC,CAcf;AA+FD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH,wBAAsB,kCAAkC,CACvD,EAAE,EAAE,QAAQ,EACZ,QAAQ,EAAE,WAAW,CAAC,MAAM,CAAC,GAC3B,OAAO,CAAC,IAAI,CAAC,CAwCf"}