Re: After Trigger assignment to NEW - Mailing list pgsql-sql
From | Achilleus Mantzios |
---|---|
Subject | Re: After Trigger assignment to NEW |
Date | |
Msg-id | Pine.LNX.4.44.0602250917250.24445-100000@matrix.gatewaynet.com Whole thread Raw |
In response to | Re: After Trigger assignment to NEW ("Owen Jacobson" <ojacobson@osl.com>) |
Responses |
Re: After Trigger assignment to NEW
(Stephan Szabo <sszabo@megazone.bigpanda.com>)
|
List | pgsql-sql |
O Owen Jacobson έγραψε στις Feb 24, 2006 : > Achilleus Mantzios wrote: > > > O Tom Lane έγραψε στις Feb 24, 2006 : > > > > > By definition, an AFTER trigger is too late to change what was > > > stored. Use a BEFORE trigger. > > > > Too late if someone wants to store it. > > I wanna store the intented original values, thats why i use > > AFTER trigger. > > But i would like to alter what a final AFTER trigger would see. > > > > I'll elabarote a little. > > > > An update happens. > > The row is stored. > > An after trigger is fired that alters some NEW columns > > (nullifies them), aiming for a subsequent trigger > > to see the altered results . > > > > It should be something like a pointer to a HeapTuple, (right?), > > so that would be feasible i suppose. > > > > I would not even make a post if it was something that trivial. > > > > I hope you get my point. > > Your real problem is that the "subsequent" trigger has behaviour you don't like. That's what you should be fixing. Ifdbmirror has no way to exclude specific tables from mirroring, take it up with them as a feature request, or patch dbmirrorto work how you want it to. > > AFTER triggers *must* receive the row that was actually inserted/updated/deleted. If they could receive a "modified" rowthat didn't reflect what was actually in the database, all sorts of useful trigger-based logging and replication patternswouldn't work, and there's really no other way to implement them. See also Tom Lane's other message for furtherimplications of being able to modify the rows seen by AFTER triggers. > As i have explained my dbmirror is FK null values gnostic(=aware) already as we speak. It normaly mirrors father rows according to certain criteria. (And the fathers of them and so on). Replication is done over UUCP over 5$/min satelite connections, so replicating just the right data for a slave is critically important. So nullifying a value just before the dbmirror trigger would do exactly the right thing (for me) Now implementing the "nullification on demand" feature in dbmirror means more work when i migrate to 8.x, i have severly modified dbmirror to do many things, and i thought it was time to stop! > I'd also be hesitant to write triggers that have to execute in a specific order. Meaning that would hurt portability? Most people need features rathen than the relief to know they can migrate to another database (which they probably never will) > Back to AFTER trigger changing values issue, i think things are not so dramatic if FK triggers could just be fired first. Anyway i'll modify dbmirror again. Oh BTW, There is a patch for DBMirror.pl (which steven hasnt yet fully reviewed) that solves the previous performance problems. > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- -Achilleus