X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 434D2D1B8B9 for ; Mon, 17 Nov 2003 15:17:26 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 82705-08 for ; Mon, 17 Nov 2003 11:16:57 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 81A77D1B50A for ; Mon, 17 Nov 2003 11:16:53 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id C9BBE353DF; Mon, 17 Nov 2003 07:16:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id C8901353CD; Mon, 17 Nov 2003 07:16:51 -0800 (PST) Date: Mon, 17 Nov 2003 07:16:51 -0800 (PST) From: Stephan Szabo To: Tomasz Myrta Cc: Lista dyskusyjna pgsql-sql Subject: Re: strange "not deferrable" behaviour In-Reply-To: <3FB8D437.4050902@klaster.net> Message-ID: <20031117071555.C94696@megazone.bigpanda.com> References: <3FB8D437.4050902@klaster.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/195 X-Sequence-Number: 16010 On Mon, 17 Nov 2003, Tomasz Myrta wrote: > I've got some tables defined as: > create table xx ( > some_column references master_table > > It means this column is defined by default: > NOT DEFERRABLE, INITIALLY IMMEDIATE > > I tried replacing rows in this table by new ones as: > set autocommit=off; > begin; > set constraints all deferred; > delete from .... > insert ... > insert... > commit; > I get "integrity violation"... just after "delete" > > If I well understood manual, it works like it should. I'm not sure, > because if I run this query in pgAdmin2, it works fine (why?) and > replaces rows as needed. > > When I drop this foreign key constraint (not too easy without a > constraint name) and recreate it as "DEFERRABLE", this query works fine > also in psql. > > My question is: Why my query works fine when using pgAdmin, and it fails > when using psql? Hmm, I'd suggest turning on query logging to make sure pgAdmin is doing what you expect.