import type { ResourceCtx } from '../../../core/extend-resource.js';
import type { ResolveAddonAttachmentOptions, ResolvedAddOnAttachment } from '../../platform/add-on-attachment/resolve.js';
export type ResolvedPgDatabase = ResolvedAddOnAttachment['addon'];
export type ResolvedPgDatabaseWithAttachment = {
    addon: ResolvedPgDatabase;
    attachment: ResolvedAddOnAttachment;
};
export type ResolvePgDatabaseOptions = ResolveAddonAttachmentOptions & {
    includeAttachment?: boolean;
    input?: string;
};
/**
 * Thrown by `resolvePgDatabase` when a database cannot be resolved: the app
 * has no Postgres databases, the attachment is not found, or the matched
 * attachment is not the configured Postgres service.
 */
export declare class PgDatabaseNotFoundError extends Error {
    readonly name = "PgDatabaseNotFoundError";
}
/**
 * Resolve a Heroku Postgres database add-on from an attachment identity.
 *
 * `input` selects the attachment as follows:
 *   - omitted or `''` → the `DATABASE_URL` attachment on `appIdentity`.
 *   - `parent-app::attachment-or-config-var` (e.g. `my-app::DATABASE_URL`)
 *     → an attachment or config var on `parent-app`.
 *   - `parent-app::branch-name` (e.g. `my-app::my-branch`) → branch add-on
 *     name on `parent-app`.
 *   - any other string (attachment name, config var, UUID, or
 *     globally-unique add-on name) → routed through `resolveAddonAttachment`,
 *     scoped to `appIdentity`.
 *
 * This function intentionally relies on the attachment resolve endpoint. To
 * resolve a database through the add-on resolve endpoint, call `resolveAddon`
 * directly.
 *
 * The returned add-on is the identity nested on the attachment (`id`,
 * `name`, `app`, and the plan stub), not a full `ResolvedAddOn`. To get
 * that shape, call `resolveAddon` with the returned add-on's `id`.
 *
 * A single resolver match is returned directly.
 *
 * If the resolver finds multiple matches that all point to the same add-on
 * (same `addon.id`/attachment `app.id`) and whose own `_URL` config var
 * resolves to the same value on the app, they're treated as equivalent
 * (e.g. the same database attached under two names) rather than ambiguous.
 *
 * If the resolver finds no match at all, falls back to treating `input` as
 * a literal config var name (adding a `_URL` suffix if missing) and looking
 * for a Postgres attachment on the app whose own `_URL` config var resolves
 * to the same value. This covers an app config var that is not one of the
 * attachment's own config vars, but whose value is the same database URL.
 *
 * Throws a `PgDatabaseNotFoundError` when the resolve endpoint 404s, the matched
 * attachment is not the configured Postgres service, or the app has no databases.
 * Throws an `AddonAttachmentAmbiguousError` when the remaining matches are not
 * the same database. Throws a plain `Error` if `appIdentity` is empty and `input`
 * has no `::`-prefixed app to fall back on.
 *
 * `resolvePgDatabase` should not throw a bare `NotFoundError`. Extensions that
 * use it typically couple it with a second data call (e.g. `data.database.info(addon.id)`)
 * that can also 404. Callers often catch `NotFoundError` to handle that second
 * call's failure specifically. However, if a resolution failure surfaced as a
 * `NotFoundError` too, that catch would swallow it and mislabel it as the second
 * call's failure instead. Resolution failures are reported as `PgDatabaseNotFoundError`
 * so the two stay separable by type.
 */
export declare function resolvePgDatabase(ctx: Pick<ResourceCtx, 'platform'>, appIdentity: string, options: ResolvePgDatabaseOptions & {
    includeAttachment: true;
}): Promise<ResolvedPgDatabaseWithAttachment>;
export declare function resolvePgDatabase(ctx: Pick<ResourceCtx, 'platform'>, appIdentity: string, options?: ResolvePgDatabaseOptions): Promise<ResolvedPgDatabase>;