Re: Referential integrity vulnerability in 8.3.3

Поиск
Список
Период
Сортировка
От Sergey Konoplev
Тема Re: Referential integrity vulnerability in 8.3.3
Дата
Msg-id c3a7de1f0807150702s2e2e41f5ve1bbfe2f8bcdd97a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Referential integrity vulnerability in 8.3.3  (Richard Huxton <dev@archonet.com>)
Ответы Re: Referential integrity vulnerability in 8.3.3  (Richard Huxton <dev@archonet.com>)
Re: Referential integrity vulnerability in 8.3.3  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Unicode database on non-unicode operating system
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Psql crashes with Segmentation fault on copy from