/**
 * Sub-object identities: the column or constraint a single `ALTER TABLE`
 * statement adds.
 *
 * `identityOf` summarizes an ALTER TABLE by the table it targets — the right
 * grouping key for object-level changes, but lossy one level down: the added
 * column's `colname` and the added constraint's `conname` stay behind in the
 * raw parse node (`facts.stmt`). This module recovers them, giving the
 * change-granularity pipeline a stable identity (and naming-spec path) for
 * every alteration.
 */
import type { ObjectIdentity } from '@pgpmjs/naming-spec';
import type { StatementFacts } from '@pgsql/semantics';
/**
 * The column or constraint a one-command `ALTER TABLE .. ADD COLUMN` /
 * `ADD CONSTRAINT` statement adds, as a naming-spec identity
 * (`kind: 'column' | 'constraint'`, `table` set). Unnamed constraints get
 * their Postgres default name. Returns `null` for anything else — multi-
 * command ALTERs, other subtypes, non-ALTER statements — so callers fall
 * back to object-level grouping.
 */
export declare function subObjectIdentityOf(facts: StatementFacts): ObjectIdentity | null;
/**
 * Rewrite a script so every unnamed `ALTER TABLE .. ADD <constraint>` carries
 * its Postgres default name (`ADD PRIMARY KEY (id)` becomes `ADD CONSTRAINT
 * {table}_pkey PRIMARY KEY (id)`) — the exact name the catalog would assign
 * anyway. Naming them makes each constraint change independently revertible
 * (`DROP CONSTRAINT <name>`) and verifiable. Statements that need no rewrite
 * keep their original text.
 */
export declare function nameUnnamedConstraints(sql: string): string;