2

ダンプからデータベースを復元するために、データベースのすべてのテーブルで、空にしたコンテンツ（postregsql 8.3）のすべての制約を一時的に無効にします。

制約を簡単にバイパスできるpg_constraintテーブルのフィールドを変更する安全な方法はありますか？

ドキュメントpg_constraintを見ると、そうは思いません。

pg_constraintテーブルの内容を削除してから、再度入力することはできますか？

そうでない場合、制約と外部キーでいっぱいのテーブルを使用してデータベースを復元/コピーするにはどうすればよいですか？（宛先データベースにはスキーマがありますが、すべての列が空です）。

編集： Erwin Brandstetterの答えは私の正確な質問に対する良い答えですが（賢明な警告付き）...復元中の外部キーエラーを回避するための私の一般的な問題の解決策は、pg_restoreを使用するときにフラグ--disable-triggersを使用することです。

最後に、私の2行のコマンドは次のようになります。

pg_dump.exe  -h %ipAddress% -p 5432 -U postgres -F c -a -v -f %file% mydb
pg_restore.exe -h localhost -p 5432 -U postgres -d mydb -v %file%  --disable-triggers

そしてそれは大丈夫です。

4

2 に答える 2

5

あなたはできる ...

ALTER TABLE tbl DISABLE TRIGGER ALL;

これにより、テーブルのすべてのトリガーが永続的に無効になります。したがって、後で実行することを忘れないでください。

ALTER TABLE tbl ENABLE TRIGGER ALL;

->8.3マニュアル

あなたはできる ...

SET CONSTRAINTS ALL DEFERRED;

これにより、すべての延期可能な制約がトランザクションの終了まで待機します。
->8.3マニュアル

ハッカーであり、自分が何をしているのかを正確に理解していない限り、システムカタログのテーブルを手動でいじってはいけません。致命的な人間は、システムカタログに影響を与えるためだけにDDLコマンドを使用する必要があります。

于 2012-08-23T14:30:56.070 に答える
3

制約がDEFERRABLEの場合、これを行うことができます。

SET CONSTRAINTS DEFERRED

ただし、これは次の制約チェックを移動するだけCOMMITです。つまり、トランザクションごとです。

通常、データを移動する場合は、ある種のバックアップ戦略を展開します。

于 2012-08-23T14:28:52.950 に答える