Updating a materialized view in my case. It should only update when 2-3 of our 30+ tables get new data, which for those is kind of rare. Not having such a trigger means I will have to call it in each usage in the code and hope future maintainers don't forget it. This is why I postponed migrating the one search query where materialized views would be useful, because it's heavy.
I don't understand why maintaining rows once per transaction saves any effort/provides any convenience.
Would the TransactionTrigger get access to changed rows? Can't you just use deferred triggers?
I'm not clear exactly when such a trigger should run. If the trigger issues more SQL, which also has triggers... do we run the PreCommit trigger twice? Or just accept that we wanted it to run just prior to commit but it kinda didn't?
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
