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 1E459D1C517 for ; Sun, 1 Feb 2004 05:48:31 +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 99611-05 for ; Sun, 1 Feb 2004 01:48:14 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 8EB74D1D2C5 for ; Sun, 1 Feb 2004 01:48:13 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 368023557C; Sat, 31 Jan 2004 21:48:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id F159B3553E; Sat, 31 Jan 2004 21:48:12 -0800 (PST) Date: Sat, 31 Jan 2004 21:48:12 -0800 (PST) From: Stephan Szabo To: Tom Lane Cc: Enio Schutt Junior , pgsql-sql@postgresql.org Subject: Re: Sometimes referential integrity seems not to work In-Reply-To: <9148.1075592448@sss.pgh.pa.us> Message-ID: <20040131214655.W11452@megazone.bigpanda.com> References: <20040126175147.B3BD046E09@mail.passofundo.rs.gov.br> <20040131124500.H98710@megazone.bigpanda.com> <9148.1075592448@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/1 X-Sequence-Number: 16692 On Sat, 31 Jan 2004, Tom Lane wrote: > Stephan Szabo writes: > > On Mon, 26 Jan 2004, Enio Schutt Junior wrote: > >> In a database I am working, I sometimes have to delete all the records in > >> some tables. According to the referential integrity defined in the creation > >> of the tables, postmaster should not delete the records, but it does. I have > >> used the following commands: "delete from table_1" and "truncate table_1". > >> ... > >> can the postgres user delete records despite referential integrity? > > I think the first PG release or two that had TRUNCATE TABLE would allow > you to apply it despite the existence of foreign-key constraints on the > table. Recent releases won't though. Yeah, truncate didn't worry me much, but the implication that delete from table_1; worked did.