"Tommy McDaniel" <tommst...@myway.com> writes: > I can understand firing the triggers. But what's up with not checking that > the foreign key constraint is met? If the user has to manually ensure that > values maintain referential integrity, why have foreign keys at all? The > whole point of foreign keys is to make the database ensure referential > integrity is maintained instead of having to do it manually.
[ shrug... ] The database is doing its best. Do you really want us to incur the extra overhead of checking that a trigger didn't screw things up? Exactly how far should that go? For instance, maybe we have to check that the trigger didn't queue a subsequent event that will make the undesired change after we look? I can assure you that far more people would complain about the useless overhead induced by rechecking than will complain about the fact that they can write triggers that will fire on RI updates. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs