Message-ID: <004b01c361b5$5fbf1900$0403a8c0@fejleszt4>
From: "=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano@mailbox.hu>
To: <pgsql-sql@postgresql.org>
References: <001001c36183$4f636570$0403a8c0@fejleszt4>
	<200308130754.32211.jgardner@jonathangardner.net>
	<003e01c361b1$37d02780$0403a8c0@fejleszt4>
	<200308130855.04062.josh@agliodbs.com>
Subject: Re: Order of triggers - totally lost
Date: Wed, 13 Aug 2003 18:10:11 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit

Dear Josh,

thanks for the guidelines.

----- Original Message ----- 
From: "Josh Berkus" <josh@agliodbs.com>
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 -------------------------------