(unnamed)
text/enriched
hi,
i was building a testdb for development. i did a pg_dump -t
to get the tables that i needed. i then loaded those objects
with psql testdb << dump.file. when i tried to do an update
against one of the tables i got this error message:
<color><param>ffff,0000,0000</param>psql:update.sql:5: pqReadData() --
backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
psql:update.sql:5: connection to server was lost
</color>i got a similar error for insert, delete, or truncate but i could
read
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.
of course since i could still select from the table i guess i could go
microsoft and say that it's actually a "read only" feature of postgres!
:)
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?
it took me a while to figure this one out. you cannot create a foreign
key to or from a non-existing table but the already generated triggers
from previous valid constraint creations will reload, in situations
such
as my test database scenario up above, without initial complaint.
xxxooo
mikeo