Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 966B9475C17 for ; Tue, 28 May 2002 10:40:13 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id E59D4475924 for ; Tue, 28 May 2002 10:38:09 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4SEc6W02979; Tue, 28 May 2002 10:38:06 -0400 (EDT) To: schaefer@alphanet.ch Cc: pgsql-sql@postgresql.org Subject: Re: Some additional PostgreSQL questions In-reply-to: References: Comments: In-reply-to schaefer@alphanet.ch message dated "Tue, 28 May 2002 09:40:48 +0200" Date: Tue, 28 May 2002 10:38:06 -0400 Message-ID: <2976.1022596686@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200205/293 X-Sequence-Number: 7928 schaefer@alphanet.ch writes: > The funny thing is the DELETE not saying an error, but not deleting (which > is good, but I would like an error). >> >> Then make your trigger raise an error. Returning NULL out of the > It does: Hm. The "NEW.lot" part will not work in an AFTER DELETE trigger (I'm a bit surprised that it doesn't raise an error --- I guess it is inserting a NULL instead). You want OLD.lot for the DELETE case. I don't know why you are getting the DELETE 0 result, but it's not because of this trigger. AFTER triggers can't suppress individual row actions, because the action is already done --- the most they can do is raise an error to abort the whole transaction. Perhaps you still have a BEFORE trigger in there somewhere? regards, tom lane