INITIALLY is used inside a table or constraint definition together with the DEFERRABLE clause. It tells the database engine whether a DEFERRABLE constraint should be evaluated right after each statement (INITIALLY IMMEDIATE) or postponed until the end of the transaction (INITIALLY DEFERRED) unless explicitly overridden with SET CONSTRAINTS. If the parent DEFERRABLE clause is omitted or NOT DEFERRABLE is specified, INITIALLY may not be used. The keyword affects FOREIGN KEY, UNIQUE, CHECK, and EXCLUDE constraints that support deferrability. Developers can later override the default timing for the current transaction by issuing SET CONSTRAINTS ALL IMMEDIATE or SET CONSTRAINTS constraint_name DEFERRED. INITIALLY does not influence performance beyond when validation occurs, but getting the timing wrong can surface constraint-violation errors earlier or later than intended.
Mode
(string) - allowed values:• DEFERRED
- validate the constraint at COMMIT time• IMMEDIATE
- validate the constraint after each statementDEFERRABLE, SET CONSTRAINTS, FOREIGN KEY, CHECK constraint, EXCLUDE constraint, DEFERRED, IMMEDIATE
SQL-92 standard; implemented in PostgreSQL 7.3
INITIALLY DEFERRED waits until COMMIT to validate the constraint. INITIALLY IMMEDIATE validates right after each statement, catching violations sooner.
Yes. Use ALTER TABLE ... ALTER CONSTRAINT ... INITIALLY IMMEDIATE or INITIALLY DEFERRED. You can also override the timing inside a single transaction with SET CONSTRAINTS.
No. These systems do not implement DEFERRABLE constraints, so INITIALLY is unrecognized and will raise a syntax error.
Only indirectly. DEFERRED constraints postpone checks, which can make individual statements faster but commit slower if violations exist. IMMEDIATE constraints detect issues earlier but may slow each statement slightly.