X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id A73C19DCE01 for ; Fri, 24 Feb 2006 14:58:30 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 80483-01-2 for ; Fri, 24 Feb 2006 14:58:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from nelson.osl.com (216-21-133-120.ip.van.radiant.net [216.21.133.120]) by postgresql.org (Postfix) with ESMTP id 9FB7F9DCDE4 for ; Fri, 24 Feb 2006 14:58:26 -0400 (AST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: After Trigger assignment to NEW Date: Fri, 24 Feb 2006 10:58:25 -0800 Message-ID: <144D12D7DD4EC04F99241498BB4EEDCC23419A@nelson.osl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SQL] After Trigger assignment to NEW Thread-Index: AcY5ckTG5r9pIDKlQMmq2nmqs+xVPQAAC8qA From: "Owen Jacobson" To: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.129 required=5 tests=[AWL=0.129] X-Spam-Score: 0.129 X-Spam-Level: X-Archive-Number: 200602/303 X-Sequence-Number: 24313 Achilleus Mantzios wrote: > O Tom Lane =DD=E3=F1=E1=F8=E5 =F3=F4=E9=F2 Feb 24, 2006 : >=20 > > By definition, an AFTER trigger is too late to change what was > > stored. Use a BEFORE trigger. >=20 > Too late if someone wants to store it. > I wanna store the intented original values, thats why i use=20 > AFTER trigger. > But i would like to alter what a final AFTER trigger would see. >=20 > I'll elabarote a little. >=20 > 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 . >=20 > It should be something like a pointer to a HeapTuple, (right?), > so that would be feasible i suppose. >=20 > I would not even make a post if it was something that trivial. >=20 > 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. If dbmirror has no way = to exclude specific tables from mirroring, take it up with them as a = feature request, or patch dbmirror to work how you want it to. AFTER triggers *must* receive the row that was actually = inserted/updated/deleted. If they could receive a "modified" row that = didn't reflect what was actually in the database, all sorts of useful = trigger-based logging and replication patterns wouldn't work, and = there's really no other way to implement them. See also Tom Lane's = other message for further implications of being able to modify the rows = seen by AFTER triggers. I'd also be hesitant to write triggers that have to execute in a = specific order.