Jan Wieck wrote:
> On 9/12/2008 12:59 PM, Andrew Sullivan wrote:
>> On Fri, Sep 12, 2008 at 05:09:13PM +0200, Cyril SCETBON wrote:
>>> yes !!! but the field bulk updated won't be updated by our 
>>> application at the same time
>>
>> Nope, can't be done.
>
> Andrew is right. There would be an elegant mechanism that allows you 
> to suppress the deny access trigger from firing when you update the 
> subscribers. But there is no such way short of dropping/recreating the 
> log trigger for that particular table on the origin. To be consistent 
> though, you'd have to do DROP,UPDARE,CREATE all in one transaction and 
> make sure through some where clause that you will hit exactly the same 
> rows on all nodes ... which also assumes that all subscribers have 
> caught up to the point where the update was done on the origin.
Bad news :-( It would really be great to have such an option. as DROP 
trigger is a DDL statement it can't be done in a transaction (afaik) 
without disturbing other transactions, so maybe another way could to 
start a transaction, updating a field (disable_trigger_work=1) in a 
table, doing all the DML, setting the field to the origin value 
((disable_trigger_work=0) and ending the transaction. But this way, it 
adds a select for every trigger call. It can be a starting point

>
>
> Jan
>

-- 
Cyril SCETBON