import type { TableDescriptor, ViewColumnDescriptor } from "./types.js";
/** The codegen-side description of a view column: physical, but untyped. */
export type ExpectedViewColumnInput = {
    kind: "passthrough";
    name: string;
    sourceTable: string;
    sourceColumn: string;
} | {
    kind: "aggregate";
    name: string;
    sourceTable: string;
    sourceColumn: string;
    agg: string;
};
/**
 * Can `existing` be turned into `target` with a `CREATE OR REPLACE VIEW`?
 *
 * Postgres permits it only when the new query produces the same columns as the existing
 * view — same names, same types, same order — with additions allowed at the END.
 * Formally: `existing` must be a PREFIX of `target`.
 * https://www.postgresql.org/docs/current/sql-createview.html
 *
 * Used in BOTH directions. Forward (target = expected, existing = live) it decides
 * replace-vs-drop. Backward, in a down migration (target = the old view, existing = the
 * one we just created), it decides the same thing — and usually says NO, because undoing
 * an append means REMOVING a column, which OR REPLACE cannot do.
 *
 * Fails SAFE: unknown columns on either side → false → the caller uses drop+create.
 * A wrong "yes" is not a failed check, it is a statement Postgres rejects at APPLY time,
 * aborting the migration with no plan-time warning.
 */
export declare function viewReplaceIsLegal(target: readonly ViewColumnDescriptor[] | undefined, existing: readonly ViewColumnDescriptor[] | undefined): boolean;
/**
 * Resolve every view column against the expected TABLE descriptors.
 *
 * Returns undefined if ANY column cannot be resolved — a partial list is worse than
 * none, because the prefix comparison would silently compare the wrong positions.
 */
export declare function resolveViewColumns(inputs: readonly ExpectedViewColumnInput[] | undefined, tables: readonly TableDescriptor[]): ViewColumnDescriptor[] | undefined;
//# sourceMappingURL=view-column-types.d.ts.map