Re: I dont get it,
От | Michael Ben-Nes |
---|---|
Тема | Re: I dont get it, |
Дата | |
Msg-id | 447545F4.20604@canaan.co.il обсуждение исходный текст |
Ответ на | Re: I dont get it, dump / restore failures to the same cluster. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom Lane wrote: > Michael Ben-Nes <miki@canaan.co.il> writes: > >> pg_dump -Fc sourcedb > sourcedb-Fc.dump >> pg_dump -a sourcedb > sourcedb.dump >> createdb test >> pg_restore -c -s -d test sourcedb-Fc.dump >> psql test < sourcedb.dump >> > > Is there a particularly good reason for doing it that way? > Yep, the reason is that im trying to migrate the cluster from iso-8859-8 to UTF-8. So I run a PHP script on an uncompressed dump, that replace few illegal characters ( like long dash ) with the appropriate ones. Then i run iconv and the result is fed to a UTF-8 cluster / db. I tried handling the Custom dump, but its compressed. Is there another practical way migrating the cluster beside dropping / adding FK ? ? > >> I got few errors ( here are some of them ): >> ERROR: insert or update on table "logo_product" violates foreign key constraint "logo_product_product_id_fkey" >> > > In general, separate schema and data restore doesn't work in the > presence of foreign keys. (This is probably impossible for pg_dump > to handle fully, because there could be circular FK dependencies; > so it doesn't even try ATM.) Do it the easy way and use a combined > schema-plus-data dump/restore. Or if you've just got to do it that > way, drop the FK constraints, load the data, re-add the constraints. > > regards, tom lane > -- -------------------------------------------------- Michael Ben-Nes - Internet Consultant and Director. http://www.epoch.co.il - weaving the Net. Cellular: 054-4848113 --------------------------------------------------
В списке pgsql-general по дате отправления: