| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joel Burton <jburton(at)scw(dot)org> |
| Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Re: a primer on trigger? |
| Date: | 2001-05-04 18:34:31 |
| Message-ID: | 27072.989001271@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Joel Burton <jburton(at)scw(dot)org> writes:
> 3) the trigger TRANSACTION_AFTER is called, and from that, we can scan the
> table, and actually do some of these system calls?
The "deferred trigger" (AFTER trigger) mechanism already does that, ie,
let you get control just before commit. However, it's no solution to
the rollback problem. What if you have several deferred triggers and
one of the later ones fails (thereby aborting the transaction)? You
already did the unreversible outside-the-database operation...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-05-04 18:38:51 | OODBMS vs. RDBMS |
| Previous Message | Bruno Wolff III | 2001-05-04 18:30:07 | Re: Case sensitive order by |