Re: a primer on trigger?
От | Joel Burton |
---|---|
Тема | Re: a primer on trigger? |
Дата | |
Msg-id | Pine.LNX.4.21.0105041505480.30777-100000@olympus.scw.org обсуждение исходный текст |
Ответ на | a primer on trigger? (newsreader@mediaone.net) |
Ответы |
Re: a primer on trigger?
|
Список | 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@scw.org> Director of Information Systems, Support Center of Washington
В списке pgsql-general по дате отправления: