> the table without error. i finally figured out that what had happened
> was that the foreign key constraints to and from that table, table x,
> that existed in production ok, had loaded into my test area but the
> associated tables that would have made those constraints valid did not
> exist; i didn't load them as i didn't need them and had forgotten>
> that there were RI constraints dependent on them.
Yep, it got noticed on -hackers a few days ago when someone reported
similar symptoms.
The message is because the backend that was handling the request crashes
in that case (so, definately a bug). The foreign key triggers need to
change a bit anyway and match partial needs to be implemented, so I
plan to put something in to give a message that is meaningful inside
the trigger if you get into this state. As for not getting into that
state, see below.
> my question is, why does postgres load up those constraints, when
> they'll
> be invalid and error out later with a vague error message, instead of
> indicating up front that those constraints are there and refuse to load
> them?
Mainly because the routine that re-adds the constraint is a much more
general routine (create constraint trigger) which doesn't know anything
about foreign keys. It's effectively the same thing as calling create
trigger for a c function on a table that exists, but giving it an arg
to one that doesn't and having the trigger try to access the table
assuming it exists (without checking that you successfully did).
Theoretically, I'd guess that the new pg_dump is going to use
alter table add constraint to add the constraints. That will prevent
this particular way of getting to the problem, although you could still
get into that state if you used a create constraint trigger manually.
