psqlと--disable-triggersを使用したプレーンテキストのpg_dumpの復元

テーブルの「レガシー」データを更新するために、短いスクリプトでいくつかのテストを実行する必要がありました。

私は慎重で、テストされていないスクリプトを使用して、その前に関連テーブルをバックアップすることにしました。これを行う最も簡単な方法は次のとおりです。

pg_dump -a --file table.sql -t table database

今、私は自分がしなければならないことをし、結果を確認しましたが、それらはかなり満足のいくものではありませんでした。私は自分自身に考えました。そのテーブルのバックアップを作成することは、どれほど幸運かです。

私がテーブルをバックアップしたとき、私はすでに警告されていました：

pg_dump: NOTICE: there are circular foreign-key constraints among these table(s):
pg_dump:   table
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.

あまり考えませんでしたが、今問題があります。実際、問題のテーブルには複数のトリガーがアタッチされていtable.sqlます--disable-triggers が、pg_restoreコマンドのwithオプションを復元できません。

次のコマンドを実行すると、エラーメッセージが表示されます。

pg_restore -a -d database -t table -h localhost --disable-triggers table.sql

つまり：

pg_restore: [archiver] input file appears to be a text format dump. Please use psql.

psqlと同じ動作を示す-コマンドのフラグはあり--disable-triggersますか？

私はすでにpsqlの「manpage」をチェックして、トリガーおよび類似のキーワードを検索しましたが、何も見つかりませんでした。

それとも、データを復元する前にテーブルのトリガーを削除する必要がある唯一のオプションですか？

_{サイドノート：Ubuntu 14.10システムでpostgres v。9.3を使用しています}

次のステートメントを含めるために、生成されたsqlファイルを編集することが提案されました。

ALTER TABLE table DISABLE TRIGGER ALL

今実行すると：psql -d database -f table.sql主キーの「一意の」制約違反に関するエラーメッセージが表示されました。

これを修正するために、コピーを次のようにラップしようとしました：

BEGIN TRANSACTION READ WRITE;
TRUNCATE TABLE table;

-- copy here

COMMIT;

現在、エラーメッセージは次のとおりです。

psql:project_backup.sql:18: ERROR:  cannot truncate a table referenced in a foreign key constraint
DETAIL:  Table "another" references "table".
HINT:  Truncate table "another" at the same time, or use TRUNCATE ... CASCADE.
psql:project_backup.sql:20: ERROR:  current transaction is aborted, commands ignored until end of transaction block
psql:project_backup.sql:21: invalid command \N
psql:project_backup.sql:22: invalid command \N

後者の警告は\N、ダンプ内の（null値を表す）それぞれに対して繰り返されます。

@dezsoは完全に正しい考えを持っていました：

これは、一部のデータが更新されたことを意味しますよね？元のデータをコピーする一時テーブルを使用して、それらを更新してみてください

今残っているのはそれを実現させることだけだった。

だからここで私がやったことです。私は彼の本から一枚の葉を取り、という名前のテーブルを使用するようにダンプファイルを手動で編集しましたtable_backup。次に、pgAdminで提供された定義を使用して上記のテーブルを作成しました（ただし、手動で行うこともできます）。

トリガーと制約、および外部キーを省略して、次のようにバックアップテーブルのデータで元のテーブルを「更新」しました。

BEGIN TRANSACTION;
ALTER TABLE table DISABLE TRIGGER ALL;

UPDATE table SET 
    (column1, column2, ...) = 
    (table_backup.column1, table_backup.colum2, ...)
FROM table_backup WHERE table.pk_column = table_backup.pk_column;

ALTER TABLE table ENABLE TRIGGER ALL;
-- I didn't but you can drop table_backup here
COMMIT;

だから私は最終的に元のデータに戻って、次のテストランの準備ができています;）

この行を.sqlデータダンプの前に追加します。

set session_replication_role = replica;

また、psqlは復元時に文句を言うべきではありません。