|
To
avoid contraints you have to use –disable-triggers flag during restore. That is
done in step 5. In
order to modify schema you have to locate what is failing. So, first restore old
schema without modifications in your new database, watch for errors and fix
them. For
example: psql
-U username -d database -h server_destination -f schema.sql
2>import_error.log You’ll
find all import errors in import_error.log. Since you are only going to launch
an schema definition, It will only take a few seconds, so test all you need. After
locating errors, open schema.sql with your favorite editor and fix them. There
are minor changes between postgresql versions and you’ll probably have no
problems in order to fix them, or ask here if you have many problems. Once
fixed, you will have your new modified_schema.sql and you can proceed with
steps 4 and 5. Obviously,
if errors are related to indexes, functions, broken dependencies, etc without touching
table definitions, everything will go well. However if you have to modify table
definitions, you will probably not be able to import data in that new schema
and it will be necesary to look for a new strategy. De: Net Tree Inc.
[mailto:nettreeinc@xxxxxxxxx] Thanks. Is it by doing these
steps I can avoid constrain restriction? for step 3, how should I modify the
schema? and which schema? the target DB's schema that I am trying to dump the
schema and data in? But this is the problem, I am not sure whats different
between the two schema's, there are just too many tables to check. What's your
tips? On Tue, Feb 23, 2010 at 7:03 PM, Iñigo Martinez Lasala <imartinez@xxxxxxxxxxxx> wrote: Using pg_dump from your new host (that is, newer version)
|
