X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 3662BD1C508; Wed, 13 Aug 2003 19:38:39 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 63044-01; Wed, 13 Aug 2003 16:37:03 -0300 (ADT) Received: from megazone.bigpanda.com (45.mufb.snfc.sffca01r18.dsl.att.net [12.103.249.45]) by svr1.postgresql.org (Postfix) with ESMTP id 0C5A6D1B53A; Wed, 13 Aug 2003 16:38:28 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 6904BD60D; Wed, 13 Aug 2003 12:38:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 5E85A5C0C; Wed, 13 Aug 2003 12:38:29 -0700 (PDT) Date: Wed, 13 Aug 2003 12:38:29 -0700 (PDT) From: Stephan Szabo To: Raymond Chui Cc: , , Subject: Re: Why table has drop, but the foreign key still there? In-Reply-To: <3F3A8010.9030701@noaa.gov> Message-ID: <20030813123631.I55790-100000@megazone.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/162 X-Sequence-Number: 9884 On Wed, 13 Aug 2003, Raymond Chui wrote: > > Here are the simple things I did > > create table state ( > state_code char(2) not null, > state varchar(15) not null, > primary key (state_code) > ); > > create table whitepage ( > user_id char(8) not null, > email varchar(50), > telephone char(16) not null, > contact_name varchar(30) not null, > city varchar(20), > state_code char(2), > primary key (user_id), > foreign key (state_code) references state (state_code) > ); > > > insert into state (state_code,state) values ('GU','Guam'); > drop table whitepage; > delete from state where state_code = 'GU'; > ERROR: Relation "whitepage" does not exist What version are you using? I can't seem to replicate this given the above on 7.2, 7.3 or 7.4. If these tables were preexisting and had gone through a dump cycle from 7.0 or 7.1, there was a bug in pg_dump for those versions that would lose the connection between the triggers and the other table of the constraint. In any case, you'll need to find and drop the two orphaned triggers on state (see techdocs for information on how to find them).