From: | Joel Burton <jburton(at)scw(dot)org> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | newsreader(at)mediaone(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: a primer on trigger? |
Date: | 2001-05-04 19:07:13 |
Message-ID: | Pine.LNX.4.21.0105041505480.30777-100000@olympus.scw.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 4 May 2001, Stephan Szabo wrote:
> > 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.
Yep, you wouldn't be able to raise a meaningful error at this point.
Comes with the territory.
Cron job scanning a table would work, and is easy to set up.
I have a personal history of moving things like databases, and not always
moving cron jobs with them. It's nice to have solutions stay somewhat
contained.
--
Joel Burton <jburton(at)scw(dot)org>
Director of Information Systems, Support Center of Washington
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Pilosov | 2001-05-04 19:12:23 | Re: debugging Pl/Tcl |
Previous Message | Stephan Szabo | 2001-05-04 18:56:11 | Re: a primer on trigger? |