Tom Lane wrote:
> * Trigger on rollback: what's that supposed to do? The current
> transaction is already aborted, so the trigger has no hope of making any
> database changes that will ever be visible to anyone.
>
It can however affect state in the backend doing the rollback, which can
be useful.
> * Trigger on commit: what do you do if the transaction fails after
> calling the trigger? The reductio ad absurdum for this is to consider
> having two on-commit triggers, where obviously the second one could
> fail.
>
Ditto - this is effectively at the point where messaging for NOTIFY
happens, and if it
fails then that's tough. If you need to implement a custom NOTIFY, this
is where to do it.
> Another response I've heard is "but I don't want to make
> inside-the-database changes, I want to propagate the state to someplace
> external". Of course that's completely broken too, because there is
>
You really are being absurdly judgemental here. _You_ may not have a
use case, but
that does not mean that no-one else does. Some things are idempotent
and are
effectively hints - that they are not transacted can be well understood and
accomodated.
Is 'Tom doesn't need it' an adequate reason to take such a hard line?
James