/**
 * Shared pg-driver value coercion helpers.
 *
 * Different pg drivers materialize `TIMESTAMPTZ` columns differently:
 *   - `node-postgres` / `pg.Pool` parses the value into a native `Date`.
 *   - `postgres.js` returns the wire-format string verbatim.
 *   - Prisma's `$queryRaw` typically returns `Date`.
 *
 * The package row mappers (`rowToRecord`, `rowToGovernanceEvent`, …) accept
 * either shape and normalize through this helper so callers always see an
 * ISO-8601 string.
 */
/**
 * Coerce a pg-driver TIMESTAMPTZ value to a CANONICAL ISO-8601 string.
 *
 * Accepts `Date` (native pg.Pool shape) or `string` (the `postgres.js`
 * wire-format shape, e.g. `"2026-05-18 00:00:00+00"`, possibly with
 * microsecond precision). Both are normalized to the canonical JavaScript
 * ISO-8601 form (`YYYY-MM-DDTHH:mm:ss.SSSZ`).
 *
 * DataReviewer-013 (option B): this read-side faithfulness is load-bearing.
 * `record.at` (and `governance_events.at`) flow through this helper into the
 * value `verifyAuditRecord` re-hashes — and `at` is part of the v4 auditHash
 * pre-image. Returning a wire-format string verbatim (the previous behavior)
 * made the read-back `at` diverge from the millisecond ISO form hashed at write
 * time, tripping a FALSE-POSITIVE tamper. Parse-and-reemit fixes the round-trip
 * without touching the core hash recipe. A canonical ISO input is idempotent
 * through `new Date(s).toISOString()`, so existing golden vectors do not move.
 *
 * Throws a diagnostic error (including the offending value) when the value is
 * neither a Date nor a parseable timestamp string — a driver bug or a misuse of
 * the reader contract, both of which deserve loud failure. `column` is used
 * only for diagnostics; when omitted the error stays informative but generic.
 */
export declare function normalizeTimestamptz(value: unknown, column?: string): string;
/**
 * Coerce a pg-driver `BIGINT` column value to a JS `number`.
 *
 * Different pg drivers materialize `BIGINT` differently: `node-postgres`
 * returns it as a `string` (to avoid silent precision loss past 2^53), while
 * some drivers return a `number`. The guard-stats / reservation `count` column
 * (migration-006 `BIGINT`) flows through this helper so callers always see a
 * `number`.
 *
 * 053 — the reservation store shares the `audit_guard_stats.count` (`BIGINT`)
 * column with the additive guard-stats counter, so its read-back path coerces
 * the same way. Counts are small aggregate tallies well within `Number`'s safe
 * integer range; a value past `Number.MAX_SAFE_INTEGER` (which a real cumulative
 * cap should never approach) throws loudly rather than returning a silently
 * lossy number — a lossy cap read would be a correctness hazard for the
 * over-commit guard, so it deserves loud failure.
 */
export declare function coerceBigIntCount(value: unknown, column?: string): number;
//# sourceMappingURL=pg-types.d.ts.map