NOT DEFERRABLE vs. DEFERRABLE INITIALLY IMMEDIATE constraints - Mailing list pgsql-general

From Jeff Janes
Subject NOT DEFERRABLE vs. DEFERRABLE INITIALLY IMMEDIATE constraints
Date
Msg-id CAMkU=1zQ0YtnthMSsDPuDfcmzL5jwZ-GbJNwB-LJS7Q7gJCK0A@mail.gmail.com
Whole thread Raw
Responses Re: NOT DEFERRABLE vs. DEFERRABLE INITIALLY IMMEDIATE constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I've been plagued several times by NOT DEFERRABLE constraints.  Is there any good reason to define a constraint as NOT DEFERRABLE rather than DEFERRABLE INITIALLY IMMEDIATE?  For example, is there performance penalty for PostgreSQL being prepared to defer a constraint even though it is not currently being deferred?

The only downside I see to DEFERRABLE INITIALLY IMMEDIATE is that a naive user could needless set it to deferred, and thus use more memory/time than they otherwise would.  But there are so many ways for naive users to shoot themselves in the foot, I fail to see the point in foreclosing this one possibility.

Cheers,

Jeff

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: Ordering Results by a Supplied Order
Next
From: Tom Lane
Date:
Subject: Re: NOT DEFERRABLE vs. DEFERRABLE INITIALLY IMMEDIATE constraints