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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
