DEFERRED is a transactional keyword used with constraints to delay their enforcement until the end of the current transaction. When a constraint (typically a FOREIGN KEY, UNIQUE, CHECK, or PRIMARY KEY) is declared DEFERRABLE and set to DEFERRED, the database allows temporary violations inside the transaction block. All deferred constraints are validated just before COMMIT. This behavior enables complex batch updates, circular foreign-key inserts, or bulk data loads that would otherwise fail on immediate constraint checks. DEFERRED can be applied in two ways: (1) at definition time with the clause DEFERRABLE INITIALLY DEFERRED, making the constraint start each transaction in the deferred state, or (2) at runtime with the statement SET CONSTRAINTS ... DEFERRED, switching one or more constraints to deferred mode for the current transaction. Some dialects such as SQLite also accept BEGIN DEFERRED TRANSACTION to start a lock-free transaction that behaves similarly. Non-DEFERRABLE constraints always fire immediately, and attempting to defer them raises an error. Because all deferred checks run at COMMIT, they can still block the commit if violations remain.
PostgreSQL 7.3 (SQL standard: SQL-92 for DEFERRABLE)
DEFERRABLE marks a constraint as capable of being deferred. DEFERRED is the actual state that postpones its enforcement until commit.
Yes. Use SET CONSTRAINTS constraint_name DEFERRED inside a transaction to target individual constraints.
Minimal overhead is added because checks are batched at commit. However, large transactions may delay error detection until the end, making debugging harder.
Query the catalog view pg_constraint in PostgreSQL or user_constraints in Oracle, filtering on deferrable = 'YES'.