Отключить проверку внешнего ключа PostgreSQL для миграции

Question 1

Я создаю много миграций с внешними ключами в PostgreSQL 9.4.

Это создает головную боль, потому что все таблицы должны быть в точном порядке, ожидаемом внешними ключами при их переносе. Это становится еще более липким, если мне приходится запускать миграции из других пакетов, от которых мои новые миграции зависят от внешнего ключа.

В MySQL я могу упростить это, просто добавив SET FOREIGN_KEY_CHECKS = 0;в начало файла миграции. Как я могу сделать это временно в PostgresSQL только на время кода миграции?

Кстати, используя для этого Laravel Schema Builder.

Question 2

PostgreSQL не поддерживает никаких параметров конфигурации, но есть и другая возможность.

postgres=# \d b
        Table "public.b"
┌────────┬─────────┬───────────┐
│ Column │  Type   │ Modifiers │
╞════════╪═════════╪═══════════╡
│ id     │ integer │           │
└────────┴─────────┴───────────┘
Foreign-key constraints:
    "b_id_fkey" FOREIGN KEY (id) REFERENCES a(id) DEFERRABLE

Ссылочная целостность в Postgres реализуется с помощью триггеров, и вы можете отключить триггеры для таблицы. С помощью этого метода вы можете загружать любые данные (риск), но это значительно быстрее, потому что проверка больших данных стоит дорого. И если ваша загрузка безопасна, вы можете это сделать.

BEGIN;
ALTER TABLE b DISABLE TRIGGER ALL;
-- now the RI over table b is disabled
ALTER TABLE b ENABLE TRIGGER ALL;
COMMIT;

Следующая возможность - использование отложенных ограничений. Это проверка ограничения перемещения для фиксации времени. Поэтому не следует соблюдать порядок в INSERTкомандах:

ALTER TABLE b ALTER CONSTRAINT b_id_fkey DEFERRABLE;

BEGIN
postgres=# SET CONSTRAINTS b_id_fkey DEFERRED;
SET CONSTRAINTS
postgres=# INSERT INTO b VALUES(100); -- this is not in a table
INSERT 0 1
postgres=# INSERT INTO b VALUES(10);
INSERT 0 1 
postgres=# COMMIT;
ERROR:  insert or update on table "b" violates foreign key constraint "b_id_fkey"
DETAIL:  Key (id)=(100) is not present in table "a".

Этот метод должен быть предпочтительным для вас, потому что вставленные данные будут проверяться.

Question 3

Для миграции проще отключить все триггеры с помощью:

SET session_replication_role = 'replica';

И после миграции снова включите все с помощью

SET session_replication_role = 'origin';