From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
Date: | 2010-12-13 10:42:19 |
Message-ID: | AANLkTi=0BR29ArB9DFGATyG0nocMwkJRgU8cBR2cZBK4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/12/13 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> But allow me to harbor doubts that they really
> intend to allow someone to force a constraint to be considered valid
> without any verification.
"Table constraints are either enforced or not enforced. Domain
constraints and assertions are always enforced.", 4.17.2
I don't read that as meaning that such unenforced constraints are
considered "valid". It sounds as if unenforced constraints are the
same as non-existing constraints (think: constraint "templates"),
possibly as a means to "remember" that they should be re-enabled at
some point.
I.e., marking a constraint as unenforced and then as enforced again
would be a shortcut for removing and re-adding the constraint, while
having the advantage that one doesn't have to keep a list of
constraint definitions that must be re-added.
> (In particular, can a constraint
> go from not-enforced to enforced state without getting checked at that
> time?)
I assume not.
Nicolas
From | Date | Subject | |
---|---|---|---|
Next Message | aaliya zarrin | 2010-12-13 10:48:00 | WaitLatch |
Previous Message | tv | 2010-12-13 10:41:04 | Re: proposal : cross-column stats |