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 744FA9DC9B0 for ; Wed, 1 Mar 2006 09:30:48 -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 78168-06 for ; Wed, 1 Mar 2006 09:30:51 -0400 (AST) Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 743939DC99B for ; Wed, 1 Mar 2006 09:30:46 -0400 (AST) Received: from smtp03l.fasthosts.co.uk (smtp.fasthosts.co.uk [213.171.216.50]) by svr4.postgresql.org (Postfix) with ESMTP id B5F815AF8AC for ; Wed, 1 Mar 2006 13:30:50 +0000 (GMT) Received: from aurora (host217-35-95-235.in-addr.btopenworld.com [217.35.95.235]) by smtp03l.fasthosts.co.uk (Postfix) with ESMTP id 8EFFA19B797 for ; Wed, 1 Mar 2006 13:30:41 +0000 (GMT) From: "Simon Kinsella" To: Subject: Help with trigger that updates a row prior to a potentially aborted deletion? Date: Wed, 1 Mar 2006 13:30:23 -0000 Organization: Bluefire Systems Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcY9NEiaeONP9DRKRgippiVmEcXsog== Message-Id: <20060301133041.8EFFA19B797@smtp03l.fasthosts.co.uk> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200603/6 X-Sequence-Number: 24352 Hi all, I have a situation where a DELETE operation may (correctly) fail due to a RESTRICT FK constraint. If so, I need to set a flag in the row indicating that it has been marked for deletion so that I can disregarded in subsequent queries. I'm trying to achieve this with a BEFORE DELETE trigger, which would set the 'marked_for_deletion' field to TRUE before attempting the delete proper. Then if the DELETE fails the row would still be tagged and I'd be happy. Problem is, when the DELETE operation fails with a RESTRICT VIOLATION error the entire operation is rolled back, including the BEFORE triggers, leaving me back where I started. Is there anyway to get the DELETE operation, or more specifically the FK constraint, to fail silently, i.e. to skip over the failed operation and not throw an exception? I'm really racking my brains on this one but not really getting anywhere! I have sample data defs to play with if that would be helpful. Thanks in advance! Simon Kinsella