Re: Upgrade time, dump+restore trouble.
От | Jesper Krogh |
---|---|
Тема | Re: Upgrade time, dump+restore trouble. |
Дата | |
Msg-id | 47165E55.4020807@krogh.cc обсуждение исходный текст |
Ответ на | Re: Upgrade time, dump+restore trouble. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Upgrade time, dump+restore trouble.
|
Список | pgsql-admin |
Tom Lane wrote: > Jesper Krogh <jesper@krogh.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@krogh.cc
В списке pgsql-admin по дате отправления: