On Tue, 2008-09-02 at 18:47 -0400, Alvaro Herrera wrote: > The problem is that you have to rerun the query to verify that the CHECK > condition still holds, whenever the table that the CHECK clause is > checking changes. This is rather problematic, because we'd need to make > the system aware of such reverse dependencies. Even if you re-ran the query, how do you avoid the race condition? For example: CREATE TABLE foo( ... CHECK ((SELECT COUNT(*) FROM foo) < 10) ); If another transaction commits between the time you re-run the query and the time you commit, the CHECK will be violated. >From an arbitrary subquery in a CHECK, it's hard to determine what kind of locking semantics might be necessary for inserting transactions. I think this is precisely what triggers are for. You define the error condition and the locking semantics in one procedure. Regards, Jeff Davis
