In article <[EMAIL PROTECTED]>,
Alexander Presber <[EMAIL PROTECTED]> writes:
> Hello everybody,
> Assuming I want to empty and refill table A (with roughly the same
> content, preferrably in one transaction) and don't want to completely
> empty a dependent table B but still keep referential integrity after
> the commit.
> Without disabling A's on-delete-trigger B will be be emptied on
> commit, even when I inserted exactly the same data into A that I
> deleted an instant before. That is because the trigger gets called on
> commit, no matter if the deleted rows have "reappeared".
> If I disable the trigger, My referential integrity is most likely
> corrupted.
> Is there a clever, general scheme to "recheck" and enforce foreign
> key contraints, after the responsible triggers have been disabled and
> reenabled?
> I hope this makes sense to you.
Not quite? Why do you use an explicit trigger for checking
referential integrity? Can't you just use a foreign key with "ON
DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED"?
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
