Konstantin Nikiforov <hellla...@gmail.com> writes:
> Expected result: exception will be raised before deletion of rows is
> done.
> Real result: no exception occurs. One of rows is really deleted.
> The trigger is ignored.
I believe this is intentional, though not too well documented. If we
fired statement triggers on child tables, then we'd have to fire all
such triggers, potentially on hundreds of child tables. In particular
this would result in a problem for constraint exclusion: discarding
child tables that couldn't be referenced by the query action would
result in a visible change in behavior. So the designed behavior is
that only the named target table has its statement triggers fired.
> 1. You can uncomment INSERT statement, and try again: exception
> will be thrown. BEFORE INSERT works, BEFORE delete - no.
The reason the INSERT case works is you're naming the child table
as target.
> 2. If i create trigger FOR EACH STATEMENT, it will work ok for insert,
> update and delete.
You mean FOR EACH ROW, no?
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
