Re: Question on triggers and plpgsql
От | Andrew Sullivan |
---|---|
Тема | Re: Question on triggers and plpgsql |
Дата | |
Msg-id | 20050408145928.GA27718@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: Question on triggers and plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Question on triggers and plpgsql
Re: Question on triggers and plpgsql |
Список | pgsql-sql |
On Fri, Apr 08, 2005 at 10:36:26AM -0400, Tom Lane wrote: > AFAICS the only way that you could get into a can't-roll-back situation > is if the trigger tries to propagate the update outside the database. > For instance, the proverbial trigger to send mail: once sent you can't > cancel it. But really this is dangerous even in an AFTER trigger --- > the transaction could still be rolled back after the AFTER trigger > fires. People who know more about this will no doubt correct me, but isn't such a case crying out for LISTEN/NOTIFY instead? That is, your trigger puts the mail content into a table of mails to be sent, and wakes up the mail-sender client with the NOTIFY; the NOTIFY and the commit to the mail-it table only happen in that case if the transaction commits. And since mail is async anyway, the extra few seconds shouldn't make any difference, right? A -- Andrew Sullivan | ajs@crankycanuck.ca The plural of anecdote is not data. --Roger Brinner
В списке pgsql-sql по дате отправления: