Change tables, columns, constraints, indexes, policies, grants and enums

Renders the operations to SQL (names quoted, expressions as given, each exactly one SQL expression) and runs them on one of the branch's Postgres databases as the owner (Admin only) or, with role, as that role (the SQL editor's session: your member role, then SET ROLE), in one transaction with lock_timeout (lock_timeout_ms, default 5000) and statement_timeout (60 s; 15 s for a dry run). A dry run runs the same statements and always rolls back; it evaluates your expressions (defaults, checks, USING), so their non-transactional side effects (e.g. nextval) remain. A statement that may rewrite a table over CHELABASE_TABLE_API_DRY_RUN_MAX_BYTES (default 256 MiB), and every one after it, is only rendered in a dry run (skipped), and then would_succeed is null. A table the request names that doesn't exist (and no earlier operation creates) is 404 with its op_index. Drops end RESTRICT and a request with drops returns dependents: what CASCADE would also remove beyond the request's own drop targets and their parts, and their hash. When something depends on a drop and the request confirms no cascade, the dry run and the real run alike answer 409 has_dependents with dependents, and change nothing. To cascade, send that hash as cascade.dependents_hash: the run (dry or real) locks the drop targets' tables, reads the dependents again, and refuses with 409 dependents_changed when they differ or when Postgres reports dropping anything but them and the parts of the request's other drop targets (drops that reach each other, e.g. a parent table and its child, need the hash of no dependents); a drop whose target an earlier drop of the request already removed is skipped (already_dropped). A CONCURRENTLY index operation must be the request's only operation: it runs outside a transaction (statement_timeout 900 s; a dry run only checks it), can't cascade, and when its build fails after creating its index, that INVALID index is dropped (another index of the same name never is). Postgres errors keep their fields (op_index, sqlstate, message, detail, hint, position; dry_run: true on a dry run). Each request is logged with its operation count, never its SQL.

Path ParametersCopy Anchor Link

Response BodyCopy Anchor Link