Re: a primer on trigger?

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

In response to

Responses

Browse pgsql-general by date

  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?