Комментарии 6
Тоже из-за колонки с датой прод недавно упал на час 😄
мидл-разработчик накатил
Это точно. Накатил, а потом решил поработать. С первого взгляда на запрос понятно, к чему он приведёт. Написавший такой запрос - не мидл. Мидл умеет пользоваться мозгом. А тут даже никакая мысля, очевидно, не шевельнулась: что будет с имеющимися данными, как оно будет работать. Хотя бы Алису что ли спросил, прежде, чем такое делать.
Код-ревью пройдено за три минуты.
И какой помидор этот трешак разрешил залить? Он виноват даже побольше, чем написавший это мидл.
Ещё можно добавить, что секции секционируемых таблиц нельзя убивать наживую. Сначала отцепляем, потом убиваем. И всё, разумеется, делается отдельными жобами.
Я правильно понял, что мы делаем процедуру в 4 шага, чтобы now() на константу не заменять?
И можно сделать что-то типа
DO $$
DECLARE
migration_time TIMESTAMP := now();
BEGIN
EXECUTE format(
'ALTER TABLE orders ADD COLUMN activated_at TIMESTAMP DEFAULT %L NOT NULL',
migration_time
);
END $$;Нет, неправильно ты понял. Мы делаем всё в 4 шага, потому что каждый из этих шагов максимально безопасен по сравнению с изначальным запросом.
И так сделать, конечно, можно, но результат будет…
...херовый
raise notice
'ALTER TABLE orders ADD COLUMN activated_at TIMESTAMP DEFAULT %L NOT NULL',
migration_time;
функция
now()считается изменчивой — volatile
https://www.postgresql.org/docs/current/sql-createfunction.html:
now()is a traditional PostgreSQL equivalent toCURRENT_TIMESTAMP.
https://www.postgresql.org/docs/current/sql-createfunction.html:
Also note that the
current_timestampfamily of functions qualify as stable, since their values do not change within a transaction.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как безобидный ADD COLUMN положил наш продакшен на 43 минуты (и почему Postgres 11+ вас не спасет)