Re: pgmemcache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 13, 2006, at 12:38 PM, Tom Lane wrote:

Christian Storm <christian.storm@xxxxxxxxx> 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.

I suspect that in reality you'd probably want each on-commit trigger to be it's own transaction, but it depends on what you're doing. Also, I can't see any use for them where you'd actually be interacting with the database, only if you were calling something externally via a function. One example would be sending an email out when a certain table changes; in many cases it's better to let the change happen even if the email can't be sent, and you'd rather not send an email if the transaction just ends up rolling back for some reason. And yes, you'd have to ensure you didn't code yourself up a trigger loop.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@xxxxxxxxxxxxx
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461




[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux