Dear Josh, thanks for the guidelines.
----- Original Message ----- From: "Josh Berkus" <[EMAIL PROTECTED]> Sent: Wednesday, August 13, 2003 5:55 PM > My perspective: multiple triggers of the same type on the same table are a > really bad idea if execution order matters. Any setup like this is > automatically maintenence hell, even when we add some sort of "trigger > priority" feature. No such thing here. At least, no such that may affect the same tuple (i.e. AI and AU are separate triggers, but I won't gain anything with a single AIU trigger that runs twice, in unpredictable order) > before triggers: re-formating input and inserting complex defaults before > saving to table; historical archiving of old data; data validation. > > after triggers: updating related tables; chronological logging of activity. just about the same as we use it, but just hours ago, I had to put some of the after stuff (updating related tables) to the before trigger, because it seemed to be much more simple. > > * how about FOR EACH STATEMENT triggers? > > (we only use FOR EACH ROW triggers) > > These will not work until 7.4, and then there will be some limitations (which > will hopefully go away in 7.5). Am I reading you right, and statement triggers don't work in 7.3? or some aspect of the order of statement- and row-level triggers? G. ------------------------------- cut here ------------------------------- ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
