Отличный и актуальный доклад! Пересмотрел в 2024 и порадовался за себя. Мы в компании на "оражевой линии" с тонкими клонами, с do-undo-do. Разработчики и тестировщики довольны, как слоны!
Не согласен с 1. IF [NOT] EXISTS может быть полезен. Простой пример. Миграция создает несколько индексов CONCURRENTLY, что нельзя сделать внутри транзакции. Вы должны быть готовы к тому, что миграция по какой-то причине упадет и ее придется перекатывать. Значит миграция должна быть идемпотентна. На помощь приходит CREATE INDEX CONCURRENTLY IF NOT EXISTS. Уверен, что пример не единственный.
При создании таблиц флаг if not exists использовать опасно. Есть риск не создать таблицу, которая задумывалась в миграции. Перед созданием таблицы пишите drop table if exists.
Я бы отнёс индекс как раз к единственному (или одному из очень немногих) исключений из предлагаемого правила. Но нужно строго определиться с неймингом, исключив возможность повторения названия. Иначе есть риск, что кто-то попытается создать другой по смыслу индекс с существующим именем, но заметит проблему только не получив желаемой оптимизации. А предварительный дроп одноимённого индекса сделает ещё хуже.
За знания спасибо, были кейсы, о которых я не знал. Но в примерах SQL запросы написаны маленькими буквами. Созерцал с интересом и отвращением. За снобизм извени.
Отличный и актуальный доклад!
Пересмотрел в 2024 и порадовался за себя.
Мы в компании на "оражевой линии" с тонкими клонами, с do-undo-do.
Разработчики и тестировщики довольны, как слоны!
Хороший доклад. Мне нравится их канал rupostgres. Самохвалов и Космодемьянский светилы в области postgres'а для меня)
Не согласен с 1. IF [NOT] EXISTS может быть полезен. Простой пример. Миграция создает несколько индексов CONCURRENTLY, что нельзя сделать внутри транзакции. Вы должны быть готовы к тому, что миграция по какой-то причине упадет и ее придется перекатывать. Значит миграция должна быть идемпотентна. На помощь приходит CREATE INDEX CONCURRENTLY IF NOT EXISTS. Уверен, что пример не единственный.
При создании таблиц флаг if not exists использовать опасно. Есть риск не создать таблицу, которая задумывалась в миграции.
Перед созданием таблицы пишите drop table if exists.
Я бы отнёс индекс как раз к единственному (или одному из очень немногих) исключений из предлагаемого правила. Но нужно строго определиться с неймингом, исключив возможность повторения названия.
Иначе есть риск, что кто-то попытается создать другой по смыслу индекс с существующим именем, но заметит проблему только не получив желаемой оптимизации.
А предварительный дроп одноимённого индекса сделает ещё хуже.
На каком языке излагал докладчик?
язык отличный, все понятно
За знания спасибо, были кейсы, о которых я не знал. Но в примерах SQL запросы написаны маленькими буквами. Созерцал с интересом и отвращением. За снобизм извени.
А в чем проблема писать маленькими? Caps это пережиток прошлого, его использовали когда в тектовых редакторах не было подстветки синтаксиса.
С отвращением смотрю на "извени". Это снобизм, извини.