From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Upgrade time, dump+restore trouble. |
Date: | 2007-10-17 19:11:17 |
Message-ID: | 47165E55.4020807@krogh.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Tom Lane wrote:
> Jesper Krogh <jesper(at)krogh(dot)cc> writes:
>> The tables are running a "home-made" timetravelling feature where a
>> contraint on the table implements the foreing keys on the table.
>
> You mean you have check constraints that do selects on other tables?
Yes. We do.. we have to .. in order to perserve the foreing-keys.
What we have in short is:
Added two timestamps on each columns, starttime,endtime. When endtime is
"null" the record is "current" and a view exposes this from the table.
The foreing keys are then implemented using contraints that look up the
id in the foreing table and ensures that there is a record where the
endtime is null present
> You have just found out (one reason) why that's a bad idea.
Do you have any other reasons?
>> How can I instruct pg_dumpall to turn off these constriants during
>> dump/restore?
>
> Drop the constraints in the source database.
That would be my workaround for the problem. But isn't it somehow
desirable that pg_dumpall | psql "allways" would work?
Jesper
--
Jesper Krogh, jesper(at)krogh(dot)cc
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-10-17 21:56:53 | Re: postgresql para windows para 64 bits |
Previous Message | Tom Lane | 2007-10-17 16:10:34 | Re: Upgrade time, dump+restore trouble. |