Re: Referential integrity vulnerability in 8.3.3 - Mailing list pgsql-general

From Sergey Konoplev
Subject Re: Referential integrity vulnerability in 8.3.3
Date
Msg-id c3a7de1f0807150702s2e2e41f5ve1bbfe2f8bcdd97a@mail.gmail.com
Whole thread Raw
In response to Re: Referential integrity vulnerability in 8.3.3  (Richard Huxton <dev@archonet.com>)
Responses Re: Referential integrity vulnerability in 8.3.3
Re: Referential integrity vulnerability in 8.3.3
List pgsql-general
>>
>> 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

pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unicode database on non-unicode operating system
Next
From: Bruce Momjian
Date:
Subject: Re: Psql crashes with Segmentation fault on copy from