> > 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?