foreign key problem with pg_dump under 7.3b2
I'm currently using 7.3b2 for test and development. I ran into a problem
using a dumped schema from pg_dump. After importing the dumped schema,
any delete or update involving a foreign key results in a relation 0
does not exist error. I noticed that all my foreign key declarations
were moved from the table create to separate statements at the bottom of
the dump file. Thanks in advance for any insight into this problem you
can lend.
-John
On 15 Oct 2002, John Halderman wrote:
I'm currently using 7.3b2 for test and development. I ran into a problem
using a dumped schema from pg_dump. After importing the dumped schema,
any delete or update involving a foreign key results in a relation 0
does not exist error. I noticed that all my foreign key declarations
were moved from the table create to separate statements at the bottom of
the dump file. Thanks in advance for any insight into this problem you
can lend.
If the data has moved from earlier versions (I think 7.0.x) there was a
bug in an older pg_dump that dropped a piece of information (the
related table) and the loss would be carried along. That
information is now used rather than the name passed in the args
so said dumps break on b2. Current sources should fill in the missing
information whenever possible.
On Tue, 2002-10-15 at 15:12, Stephan Szabo wrote:
On 15 Oct 2002, John Halderman wrote:
I'm currently using 7.3b2 for test and development. I ran into a
problem
using a dumped schema from pg_dump. After importing the dumped
schema,
any delete or update involving a foreign key results in a relation 0
does not exist error. I noticed that all my foreign key declarations
were moved from the table create to separate statements at the
bottom of
the dump file. Thanks in advance for any insight into this problem
you
can lend.
If the data has moved from earlier versions (I think 7.0.x) there was
a
bug in an older pg_dump that dropped a piece of information (the
related table) and the loss would be carried along. That
information is now used rather than the name passed in the args
so said dumps break on b2. Current sources should fill in the missing
information whenever possible.
Actually we are dumping from b2 to b2. Also the problem doesn't seem to
be
related to the data or missing data. I can infer this because I am doing
a schema only dump. After I import this dump i create some test data and
still run into the relation 0 does not exist error. I think it has
something to do with the way the dump defines the foreign key
constraints and triggers. Thanks again for the help.
-john
Import Notes
Resolved by subject fallback
On Tue, 2002-10-15 at 15:38, Stephan Szabo wrote:
On 15 Oct 2002, John Halderman wrote:
On Tue, 2002-10-15 at 15:12, Stephan Szabo wrote:
On 15 Oct 2002, John Halderman wrote:
I'm currently using 7.3b2 for test and development. I ran into a problem
using a dumped schema from pg_dump. After importing the dumped schema,
any delete or update involving a foreign key results in a relation 0
does not exist error. I noticed that all my foreign key declarations
were moved from the table create to separate statements at the bottom of
the dump file. Thanks in advance for any insight into this problem you
can lend.If the data has moved from earlier versions (I think 7.0.x) there was a
bug in an older pg_dump that dropped a piece of information (the
related table) and the loss would be carried along. That
information is now used rather than the name passed in the args
so said dumps break on b2. Current sources should fill in the missing
information whenever possible.Actually we are dumping from b2 to b2. Also the problem doesn't seem to be
related to the data or missing data. I can infer this because I am doing
a schema only dump. After I import this dump i create some test data and
still run into the relation 0 does not exist error. I think it has
something to do with the way the dump defines the foreign key
constraints and triggers. Thanks again for the help.Was your old b2 system loaded from a dump? If so, you'd be in the upgrade
portion of the problem. Old dumps were incorrect, and as soon as you
loaded from one of those dumps all future dumps became incorrect in the
same way. Current sources notice that the item is missing and attempts
to figure out what it should be.
Interesting, that may be it. I'll do some testing to verify your theory.
Thank you for your help.
-john.
Import Notes
Reply to msg id not found: 20021015123327.E85180-100000@megazone23.bigpanda.comReference msg id not found: 20021015123327.E85180-100000@megazone23.bigpanda.com | Resolved by subject fallback