Erwan Tanajaya-2 wrote > i do as you suggested, i returning null on the initial before delete > trigger(parrent trigger), but when i returning null no delete action is > accured. > am i doing wrong ? > > "the trigger can avoid the error by re-issuing the triggering statement > and > returning NULL" > how i re-issuing the triggering statement ?
If you are inside a DELETE trigger you would do something like:
DELETE FROM table_this_trigger_is_on WHERE pk_for_the_table = OLD.pk_for_the_table; RETURN NULL;
The returning of NULL prevents the original DELETE action but since you took care of it manually the final result is that the record in question is still gone.
Thank you very much David for your help :)
i will try immediately
That said you need to see if you can introduce logic somewhere that says: "since my parent record is going to go away anyway I should just avoid updating it in the first place".
Aside from that a self-contain and reasonably faithful reproduction of your exact problem might help you either obtain advice or make Kevin et. al. reconsider the solution put in place to avoid the problem they were facing.
Note that in the two years this patch has been in place this is the first time I recall seeing a report of this nature...which suggests there is a correct solution that you are missing. Though I am also thinking 9.3 hasn't received as much adoption in the past two years as we would have liked...
i am using 9.0 or 9.1 for long time and statisfied with this version, until ubuntu 14.04 and hosting provider force me to use newer version.
I really hope Kevin and other dev have a better solution for this case(applying those patch for update case only maybe), i don't have enough faith that i correct or something for now but if there are another person encounter the same problem that i had(and i hope they reporting it on the mailing list) maybe dev should really consider this problem.
