ダンプの復元中にすべての制約とテーブルチェックを無効にします

私は私のPostgreSQLデータベースのダンプを取得しました：

pg_dump -U user-name -d db-name -f dumpfile

次に、次のコマンドを使用して別のデータベースに復元します。

psql X -U postgres  -d db-name-b -f dumpfile

私の問題は、データベースに参照制約、チェック、トリガーが含まれていることと、これらのチェック（特にチェック）の一部が復元中に失敗することです。たとえば、テーブルへの行の挿入は、他の無関係なテーブルで条件が成立するかどうかをチェックCHECKするplpgsql関数を呼び出すに関連付けられます。後者のテーブルがpsql前者の前に読み込まれない場合、エラーが発生します。

以下は、一度ダンプするpg_dumpと復元できないデータベースを生成するSSCCEです。

CREATE OR REPLACE FUNCTION fail_if_b_empty () RETURNS BOOLEAN AS $$
    SELECT EXISTS (SELECT 1 FROM b)
$$ LANGUAGE SQL;

CREATE TABLE IF NOT EXISTS a (
     i              INTEGER                    NOT NULL
);

INSERT INTO a(i) VALUES (0),(1);
CREATE TABLE IF NOT EXISTS b (
    i  INTEGER NOT NULL
);
INSERT INTO b(i) VALUES (0);

ALTER TABLE a ADD CONSTRAINT a_constr_1 CHECK (fail_if_b_empty());

ダンプの復元中にこのような制約をすべて（コマンドラインから）無効にし、後で再び有効にする方法はありますか？PostgreSQL 9.1を実行しています。

したがって、CHECK制約内の他のテーブルを検索します。

CHECK制約はIMMUTABLEチェックを実行することになっています。一度に行にOKを渡すものは、いつでも OKを渡すはずです。これCHECKが、SQL標準での制約の定義方法です。それがこの制限の理由でもあります（ドキュメントごと）：

現在、CHECK式にはサブクエリを含めることも、現在の行の列以外の変数を参照することもできません。

現在、CHECK制約内の式は、ユーザー定義関数であっても関数を使用できます。それらはIMMUTABLE機能に制限されるべきですが、Postgresは現在これを強制していません。pgsql-hackersに関するこの関連する議論によると、1つの理由はIMMUTABLE、本来ではない現在時刻への参照を許可することです。

しかし、別のテーブルの行を検索していますが、これはCHECK制約の動作方法に完全に違反しています。pg_dumpこれを提供できなかったことに驚かない。

別のテーブルのチェックをトリガー（適切なツール）に移動すると、Postgresの最新バージョンで動作するはずです。

PostgreSQL 9.2以降

上記はPostgresのどのバージョンにも当てはまりますが、Postgres 9.2には状況に役立ついくつかのツールが導入されています。

pg_dumpオプション --exclude-table-data

簡単な解決策は、違反テーブルのデータなしでdbをダンプすることです：

--exclude-table-data=my_schema.my_tbl

次に、このテーブルのデータだけをダンプの最後に追加します：

--data-only --table=my_schema.my_tbl

ただし、同じテーブルの他の制約との合併症が発生する可能性があります。さらに良い解決策があります：

NOT VALID

NOT VALID制約の修飾子があります。v9.1ではFK制約でのみ使用できますがCHECK、9.2では制約に拡張されました。ドキュメントごと：

制約がマークされている場合、NOT VALIDテーブル内のすべての行が制約を満たすことを確認するための潜在的に長い初期チェックはスキップされます。制約は引き続き、後続の挿入または更新に対して実施されます[...]

単純なpostgresダンプファイルは、3つの「セクション」で構成されています。

• pre_data
• data
• post-data

^{Postgres 9.2では、でセクションを個別にダンプするオプションも導入されました-- section=sectionnameが、それは当面の問題には役立ちません。}

ここが面白いところです。ドキュメントごと：

ポストデータ項目には、検証済みのチェック制約以外のインデックス、トリガー、ルール、および制約の定義が含まれ ます。事前データ項目には、他のすべてのデータ定義項目が含まれます。

大胆な強調鉱山。
問題のCHECK制約をに変更してNOT VALID、制約をpost-dataセクションに移動できます。ドロップして再作成：

ALTER TABLE a DROP CONSTRAINT a_constr_1;
ALTER TABLE a ADD  CONSTRAINT a_constr_1 CHECK (fail_if_b_empty()) NOT VALID;

これで問題が解決するはずです。制約をその状態のままにしておくこともできます。これは、実際の動作をよりよく反映しているためです。新しい行をチェックしますが、既存のデータは保証しません。NOT VALIDチェック制約には何も問題はありません。必要に応じて、後で検証できます。

ALTER TABLE a VALIDATE CONSTRAINT a_constr_1;

しかし、その後は現状に戻ります。

これpg_dumpは、ダンプの作成方法によるものと思われます。実際のダンプを見るとCHECK、CREATE TABLEコマンドの一部である構文を使用して、ダンプファイルに制約が存在することがわかりました。

CREATE TABLE a (
    i integer NOT NULL,
    CONSTRAINT a_constr_1 CHECK (fail_if_b_empty())
);      

これにより、テーブルaまたはテーブルにbデータが含まれる前にチェックが行われるため、データベースの復元時に障害が発生します。ただし、ダンプファイルが編集CHECKされ、代わりに次の構文を使用して、ダンプファイルの最後に追加されます。

ALTER TABLE a ADD CONSTRAINT a_constr_1 CHECK (fail_if_b_empty()); 

...その後、復元に問題はありません。

TRIGGER次のスクリプトのように、まったく同じロジックを実装できます。

CREATE OR REPLACE FUNCTION fail_if_b_empty (
    ) RETURNS BOOLEAN AS $$
    SELECT EXISTS (SELECT 1 FROM b)
$$ LANGUAGE SQL;

DROP TABLE IF EXISTS a;

CREATE TABLE IF NOT EXISTS a (
    i   INTEGER   NOT NULL
);

INSERT INTO a(i) VALUES (0),(1);

CREATE TABLE IF NOT EXISTS b (
    i  INTEGER NOT NULL
);

INSERT INTO b(i) VALUES (0);

CREATE TRIGGER tr1 AFTER INSERT OR UPDATE ON a
FOR EACH ROW
EXECUTE PROCEDURE fail_if_b_empty();  

ただし、この場合pg_dump、ダンプファイルの最後に（デフォルトで）トリガーを作成し（CREATE TABLEチェックの場合のようにステートメント内ではない）、復元は成功します。