Re: [ADMIN] Why table has drop, but the foreign key still there?

Поиск
Список
Период
Сортировка
Искать
От
Stephan Szabo
Тема
Re: [ADMIN] Why table has drop, but the foreign key still there?
Дата
Msg-id
20030813123631.I55790-100000@megazone.bigpanda.com
Ответ на
Список
Дерево обсуждения
Why table has drop, but the foreign key still there? Raymond Chui <raymond.chui@noaa.gov>
Re: Why table has drop, but the foreign key still there? Rod Taylor <rbt@rbt.ca>
Re: [ADMIN] Why table has drop, but the foreign key still there? Tom Lane <tgl@sss.pgh.pa.us>
Re: [ADMIN] Why table has drop, but the foreign key still there? Stephan Szabo <sszabo@megazone.bigpanda.com>

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).

В списке pgsql-general по дате отправления
От:
Дата:
Сообщение: Searching Tables
От: Tom Lane
Дата:
FAQ