Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashesbackend.)

> > but a larger question is why the system let you drop a table that
> > is the target of a referential integrity check (which I assume is
> > what you did to get into this state).
>
>     For me too.
>
> > Anyway, dropping the siteid trigger, as well as any others that
> > refer to gone tables, ought to get you out of trouble for now.
> > Meanwhile the foreign-key boys have some work to do ...
>
>     That's exactly the purpose of pg_trigger.tgconstrrelid, which
>     is filled with the  opposite  relations  Oid  for  constraint
>     triggers.    In  RelationRemoveTriggers(),  which  is  called
>     during DROP TABLE, theres a scan for it. That's where the
>
>         DROP TABLE implicitly drops referential ...
>
>     NOTICE message comes from. So I wonder how he got  into  that
>     state?

I don't know in his case, but I think you could get into this state
from a partial restore from pg_dump.  If you restore one of the
two tables, and create the constraint trigger for the RI_FKey_check_ins
but the other table doesn't really exist, it will crash. I just tried it on
a 7.0.2 system by making a table with an int and then defining the
check_ins trigger manually with create constraint trigger with a bad
referenced table.

Also, I realized something else that is a little wierd.  When a temporary
table shadows a permanent table that you've made a foreign key reference
to, which table should it be going to check the constraint?