From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jordan Gigov <coladict(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Triggers on transaction? |
Date: | 2015-05-27 11:36:32 |
Message-ID: | CANP8+jJbHtqFmwCMNYxxmU+AYQWRun_TpuovW-3dihFSEYXdWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 May 2015 at 11:55, Jordan Gigov <coladict(at)gmail(dot)com> wrote:
> 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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Joseph Krogh | 2015-05-27 12:55:40 | Re: Triggers on transaction? |
Previous Message | Benedikt Grundmann | 2015-05-27 11:15:19 | Re: Triggers on transaction? |