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.
If the trigger fails it is the triggers problem, it isn't the
commit's problem, i.e., you wouldn't want to 'un-commit'. If the
trigger
gets an error it has to gracefully deal with that error programatically.
Where have I gone astray with this logic?
On Apr 12, 2006, at 5:35 PM, Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Why are AFTER COMMIT triggers impossible?
What happens if such a trigger gets an error? You can't un-commit.
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
