> Because you have an ON DELETE CASCADE. That leads to a DELETE ... WHERE
> ...
> on the slave table; whether any records actually get deleted depends on
> what the DELETE finds. This is a general hazard of using STATEMENT
> triggers: you have no info about whether the statement actually did
> anything.
Tom, thank you.
I try to implement table level replication in my application.
Last table change time is written to control table by trigger.
Client finds the tables which are changed after last login and re-loads the
whole tables. Unfortunately, ON DELETE CASCADE tables are replicated always
in this case
which slows down my application startup.
Should I use foo_trig as row level trigger to detect only real row deletion
?
> (It's rather silly to imagine that a BEFORE STATEMENT trigger
> would have any way to know that anyway. We currently don't tell an
> AFTER STATEMENT trigger anything either; though that may change
> someday.)
I tried following code:
insert into klient values (1);
update klient set kood=2 WHERE kood=3;
In this case, foo_trig trigger is NOT executed.
So BEFORE UPDATE ROW trigger is NOT executed when there are no rows to
update,
but BEFORE DELETE ROW trigger IS executed when there are no rows to delete!
Why is this behaviour inconsistent ?
Andrus.
