Re: Foreign keys for non-default datatypes
От | Michael Paesold |
---|---|
Тема | Re: Foreign keys for non-default datatypes |
Дата | |
Msg-id | 009d01c63f63$2d5400f0$0f01a8c0@zaphod обсуждение исходный текст |
Ответ на | Foreign keys for non-default datatypes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Foreign keys for non-default datatypes
|
Список | pgsql-hackers |
Tom Lane wrote: >>> If we did this then RI checks would no longer be subvertible by rules >>> or user triggers. > > Stephan Szabo writes: >> I don't think that it'd really help because it's the actions that are >> generally subvertible not the checks and since those are looking at the >> potentially not indexed fk side, I don't think the above would apply. > > Oh, right, we'd probably still need to do planning in that case. Unless > we wanted to insist on having an FK-side index too for every FK, which > is something I'm not for. I don't really understand the implications here, but I hope that the following usecase will still work afterwards: Two tables A, B. B (id) references A (id), with ON DELETE CASCADE Usually deleting a row from A will cause all referencing rows in B to be deleted, too. Nevertheless B has a BEFORE DELETE trigger "check_delete" that checks if a row of B may be deleted or not. I.e. it contains a IF ... RAISE EXCEPTION... Will this trigger still be called, so it can abort the delete? If not, I am against that change because it will break the consistency-enforcements of one of our applications. In other words, if you only change the checks of the FKs, I see no problem at all; but if you change the actions of FKs to not call user defined triggers, I have a problem. Please correct any of my wrong assumptions. ;-) Best Regards, Michael
В списке pgsql-hackers по дате отправления: