On Tue, Jul 15, 2008 at 06:02:27PM +0400, 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. > > > > 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?
The code you posted is a clear case of doing things wrong deliberately. In order to prevent this error, you would need to rewrite large parts of Postgres's code which checks referential integrity, and there would still be things that deliberately wrong DDL, triggers, rules, etc. could do. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
