Re: Referential integrity vulnerability in 8.3.3

>>
>> Yes it is. But it the way to break integrity cos rows from table2 still
>> refer to deleted rows from table1. So it conflicts with
>> ideology isn't it?
>
> Yes, but I'm not sure you could have a sensible behaviour-modifying BEFORE
> trigger without this loophole. Don't forget, ordinary users can't work
> around this - you need suitable permissions.
>
> You could rewrite PG's foreign-key code to check the referencing table after
> the delete is supposed to have taken place, and make sure it has. That's
> going to halve the speed of all your foreign-key checks though.
>

I'm not sure I've understood you right, sorry. Does "rewrite PG's
foreign-key code" mean DDL? If it does how could I do this?

--
Regards,
Sergey Konoplev