Thread: 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

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.