Christian Storm <[EMAIL PROTECTED]> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
