From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Lange <anlan(at)ida(dot)liu(dot)se> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: pg_dump table ordering bug [8.0.1] |
Date: | 2005-03-24 22:27:45 |
Message-ID: | 8829.1111703265@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andreas Lange <anlan(at)ida(dot)liu(dot)se> writes:
> Our upgrade from 7.4.6 to 8.0.1 only had one small glitch. Two tables
> got dumped in the wrong order (before their dependecies) and had to get
> their contents added manually after the restore. I've atleast isolated
> the part where things go wrong.
I don't think this is a pg_dump bug: the problem is you are abusing
check constraints to emulate foreign key constraints. pg_dump has no
way to know what those functions are doing and therefore no way to
realize that the check constraints impose a data load ordering
dependency. Furthermore, the check constraints are fundamentally wrong
anyway because they don't create a two-way relationship --- that is,
altering the referenced tables won't raise an error if the check is now
violated for something in the referencing table.
It would be best to find a way to express these relationships with
ordinary foreign keys. Maybe you could add a column to form_a_int
that is a foreign key reference to both of form_instance.fid and
form_q.fid, for example?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2005-03-24 22:28:47 | Re: BUG #1532: typecast problem between arrays of an int8 |
Previous Message | Tom Lane | 2005-03-24 20:43:52 | Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[] |