From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Joel Burton <jburton(at)scw(dot)org> |
Cc: | newsreader(at)mediaone(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: a primer on trigger? |
Date: | 2001-05-04 18:56:11 |
Message-ID: | Pine.BSF.4.21.0105041152140.60613-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 4 May 2001, Joel Burton wrote:
> Hmmm... this raises an interesting question.
>
> Would it be possible to hook into (via trigger or other mechanism) so that
> we could execute a function on commit? There are PG triggers to do things
> like send email, etc., which, yes, can't be undone if the transaction
> ultimately fails. Instead, could we:
>
> 1) have a trigger that (in this case) instead of sending email, just adds
> the information to an 'email-to-send' table.
>
> 2) commit the transaction
>
> 3) the trigger TRANSACTION_AFTER is called, and from that, we can scan the
> table, and actually do some of these system calls?
>
> Can this be done? Is this terrible design? Is there any other reasonable
> way to handle things like this?
Probably could be done, but the question would be what happens if the
TRANSACTION_AFTER raises an error condition for whatever reason? You
can't go back and un-commit the transaction.
For that case above, you'd probably be better off having something in cron
or whatever looking at your email-to-send table since it'll get only those
things that have already committed. You could put all the logic in a
function on the server still.
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Burton | 2001-05-04 19:07:13 | Re: a primer on trigger? |
Previous Message | Bruce Momjian | 2001-05-04 18:38:51 | OODBMS vs. RDBMS |