> Isn't it *supposed* to mis UNcommitted changes from other transactions?
Well, if the "uncommited change" is a DELETE of the row that allowed the
constraint check to pass, then when this delete is commited, your data is
no longer consistent.
Consider this :
CREATE TABLE A( attributes INT[], CHECK( is_valid_attributes( attributes
)) )
CREATE TABLE valid_attributes ( attribute_id INTEGER )
You want to check that A.attributes is an array of values, the only
allowed values being stored in valid_attributes table. If you delete a row
in valid_attributes, many rows in A can become invalid unless you use some
form of trigger on valid_attributes which would start to look a lot like a
foreign key ON DELETE trigger. If you insert stuff in A while concurrently
deleting a row in valid_attributes, you have problems. This is why foreign
key checks take share locks on referenced tables...