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 582A79DC85E for ; Sun, 12 Feb 2006 19:10:37 -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 46225-04 for ; Sun, 12 Feb 2006 19:10:36 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by postgresql.org (Postfix) with ESMTP id 711AF9DC84D for ; Sun, 12 Feb 2006 19:10:32 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 3930538043; Sun, 12 Feb 2006 15:10:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 3765E37F79; Sun, 12 Feb 2006 15:10:33 -0800 (PST) Date: Sun, 12 Feb 2006 15:10:33 -0800 (PST) From: Stephan Szabo To: "Foster, Stephen" Cc: pgsql-sql@postgresql.org Subject: Re: Trigger/Sequence headache In-Reply-To: <000801c63023$8e0af830$2101a8c0@cfgod> Message-ID: <20060212150559.S97294@megazone.bigpanda.com> References: <000801c63023$8e0af830$2101a8c0@cfgod> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.139 required=5 tests=[AWL=0.139] X-Spam-Score: 0.139 X-Spam-Level: X-Archive-Number: 200602/129 X-Sequence-Number: 24139 On Sun, 12 Feb 2006, Foster, Stephen wrote: > This is going to be one of those stupid problems of mine. I have an > insert trigger setup to verify that duplicate or repeating information > isn't storage in the table. If trigger function finds the information > as a duplicate it returns a NULL and the information isn't added; that > works. The problem I'm having is that it is incrementing the sequence > counter even when the data isn't added. Is this something that I have > to live with or should I be returning something other than a NULL? The sequence is going to increment upon getting the value. However, I think, if instead of using a default, you got the next value in the trigger after you determined that it wasn't a duplicate and set the field, it wouldn't increment for this case. This changes some other behaviors a little (for example DEFAULT in updates as well), so you'd need to see whether it'd be acceptable. Of course, errors, rollbacks and deletes will still leave holes.