Re: pointer to feature comparisons, please
От | PFC |
---|---|
Тема | Re: pointer to feature comparisons, please |
Дата | |
Msg-id | op.ttvrdqfycigqcu@apollo13 обсуждение исходный текст |
Ответ на | Re: pointer to feature comparisons, please (Ron Johnson <ron.l.johnson@cox.net>) |
Ответы |
Re: pointer to feature comparisons, please
|
Список | 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...
В списке pgsql-general по дате отправления: