https://www.postgresql.org/docs/current/sql-altertable.html
Благодарю, вопрос немного переформулирую, почему нельзя установить и удалить DEFERRABLE в одной транзакции?
Впервые об этом слышу — но если это правда — то потому, что core team такое низачем ненужно, а реализацыя такого требует усилий.
В одной транзакции никак не хочет, вот и спросил, может где-то это явно указано.
На деле вот как получилось. Открываешь тразакцию SET CONSTRAINTS ALL DEFERRED; Далее бегаешь по constaint и ставишь ALTER TABLE ONLY schema.table ALTER CONSTRAINT ConstraintName DEFERRABLE; Манипулируешь с данными, в моем случае подмена id. Закрываешь транзакцию. В отдельной транзакции проходишь по CONSTRAINTs ALTER TABLE ONLY schema.sable ALTER CONSTRAINT ConstraintName NOT DEFERRABLE;
И ключевой вопрос _ а нафига?
Предлагаете решать такие кейсы, как-то иначе?
То есть если у вас такое постоянно — то это сломанная идея, любой DDL на регулярной основе. А если один раз — то какая вам разница сколько там транзакцый, да и вообще, сложно отсортировать вставки что ли...
Предлагаю выбрать — хотите вы deferrable или not deferrable — и установить один раз и навсегда это.
Это разовая итерация, вопрос не в сортировке, а в разных id. На входе были другие id, нужно было данные положить получить новые id и обновить все ссылки.
Ну и обновите одним statement... казалось бы — при чём тут вообще DEFERRABLE?
Извините, не понимаю что Вы предлагаете.
Так Вы и самой проблемы-то не описали, на самом деле. ;) А предлагаю я что-то вроде WITH upd1 (UPDATE ... RETURNING ...), upd2 (UPDATE ... FROM upd1 RETURNING ...) UPDATE ...;.
Обсуждают сегодня