Tom Lane <tgl@sss.pgh.pa.us> writes:
> Christian Storm <christian.storm@gmail.com> writes:
> > Not sure if I follow why this is a problem. Seems like it would be
> > beneficial to have both BEFORE and AFTER COMMIT triggers.
> > With the BEFORE COMMIT trigger you would have the ability to 'un-
> > commit' (rollback) the transaction. With
> > the AFTER COMMIT trigger you wouldn't have that option because the
> > commit has already been successful. However,
> > with an AFTER COMMIT you would be able to trigger other downstream
> > events that rely on a transaction successfully committing.
>
> An AFTER COMMIT trigger would have to be in a separate transaction.
> What happens if there's more than one, and one of them fails? Even
> more to the point, if it's a separate transaction, don't you have
> to fire all these triggers again when you commit that transaction?
> The idea seems circular.
Maybe it just means they would have to be limited to not making any database
modifications. Ie, all they can do is notify the outside world that the
transaction committed.
Presumably if you wanted to make any database modifications you would just do
it in the transaction anyways since they wouldn't show up until the
transaction commits.
--
greg
