From: | PFC <lists(at)peufeu(dot)com> |
---|---|
To: | "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pointer to feature comparisons, please |
Date: | 2007-06-13 21:59:40 |
Message-ID: | op.ttvrdqfycigqcu@apollo13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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...
From | Date | Subject | |
---|---|---|---|
Next Message | Alejandro Torras | 2007-06-13 22:07:33 | Re: Using the GPU |
Previous Message | Joris Dobbelsteen | 2007-06-13 21:57:31 | Re: pointer to feature comparisons, please |