On Thursday 21 February 2008 12:20, Andrew Sullivan wrote:
>
> Well, you could try rewriting the function to disable all but the Slony
> trigger. But there's something else wrong here.
>
> I seem to recall that we found some code path where reltriggers wasn't
> checked properly anyway, so disabling triggers wouldn't work exactly as you
> are doing it. This was part of the reason for the catalogue-breaking oid
> fiddling Slony does on replicated tables, IIRC. So I'm not even sure your
> current approach will work reliably as you think.
>
> Probably the right answer, I'm afraid, is to change your trigger functions
> to fire more selectively, then make the disable trigger function a no-op
> (so you don't have to change all your other code right now).
>
>
> A
>
Thanks for the input. I've been using the reltriggers in pg_class for a long
time and it does work; however, I did notice in the documentation on
pg_trigger that tgenabled is not checked properly and using that will give
inconsistant results. We have several valid reasons for disabling all
triggers that I won't elaborate here.
Unless I get a better idea, I'm going to change the disable_triggers function
to duplicate all the records in pg_trigger belonging to a given table, delete
the records except for the Slony trigger, update pg_class setting reltriggers
to 1, do the work, and then restore everything with a call to
enable_triggers. Does this sound reasonable to you?
--
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30501
Tel: (336) 372-6812 Fax: (336) 372-6812 Cell: (336) 404-6987
terry@turbocorp.com
www.turbocorp.com
