On 06/29/2015 07:13 AM, gmb wrote:
> Adrian Klaver-4 wrote
>>>
>>> Some notes:
>>> It cannot be guaranteed that the above happens as a single transaction.
>>> It is possible that this occurs at the same time as other session posting
>>> inserts/updates to table TEMP.
>>
>> It can if wrapped in BEGIN/COMMIT or is there reason that is not being
>> done?
>
> Sorry , what I meant to say was that as this stage this is not implemented
> in a single transaction (with BEGIN/COMMIT).
>
>
> Adrian Klaver-4 wrote
>>> I'm seeing data which suggests that trigger trigname did not occur when
>>> in
>>> fact it should have ( i.e. the above update procedure is not relevant ).
>>> Does this make sense taking into account that multiple sessions posts to
>>> the
>>> table at once ?
>>
>> Not without knowing what the trigger procedure does?
>
> The trigger being disabled is used to post summarized numeric values to a
> summary table.
> Actually what I'm trying to do here is to reset the values in the detail
> table to zero without updating the summary tables. Afterwards I'm updating
> from a zero value which means that the difference will be posted to the
> summary table. This kind of data fix is required where data on the summary
> tables was not posted as excepted for whatever reason.
>
>
> I guess my question is:
> If I encapsulate the "disable trigger/update/enable trigger" in BEGIN/COMMIT
> to handle as single transaction, are there guarantees that the disabling of
> the trigger will not have an effect on other sessions ?
That I do not know. A thought did come to mind though. That is to add a
reset boolean column(default ='f') to your detail table and make the
trigger procedure aware of it. Then when you are resetting the values to
zero have reset = 't' and have the trigger procedure ignore those rows.
Then do the 'normal' update to update the summary table.
>
>
>
> --
> View this message in context: http://postgresql.nabble.com/Disable-Trigger-for-session-only-tp5855658p5855697.html
> Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
