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

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

--
   Richard Huxton
   Archonet Ltd

pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unicode database on non-unicode operating system
Next
From: Yi Zhao
Date:
Subject: Re: how to found a variable is in a aggregation or not?