Re: a primer on trigger?

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.

In response to

Responses

Browse pgsql-general by date

  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