Re: Affected # of Rows After TRIGGER/RULE Return

On Wed, 14 May 2008, Gerald Quimpo <bopolissimus(dot)lists(at)gmail(dot)com> writes:
> Instead of trying to update the row in place, insert the row again,
> but with the field you need to mangle (in your example, "plate",
> in my example below, "k") already mangled. this only works if
> the field you're mangling is the primary key. if some other field
> is the primary key, you will need to mangle that too, if possible.
> since you'll have already inserted the row, just return OLD and let
> the old row actually be deleted.

I've considered that too. But the problem is that there are nearly 50-60
tables referencing to the related row about the be deleted. Therefore,
if I'd return OLD from the trigger, all other rows referencing to OLD
will get deleted because of ON DELETE CASCADE. But, if there would be
some way to tell the ON DELETE CASCADE constraints that "Hey, don't move
yet. I'll INSERT a new row with what you thought to be missing
previously." there won't be a problem.

I hope I understand you correctly. Did I miss anything? Any ideas?

Regards.