Postgres Guru | Базы данных

🤖 Обращение к предыдущим (OLD) и к текущим (NEW) значениям в предложении RETURNING в PostgreSQL 18. Всем привет! Помимо таких ключевых функций в PostgreSQL 18, как асинхронный ввод-вывод и поддержка UUIDv7, мы получили вот такое небольшое, но приятное улучшение. В этой версии добавлена возможность обращаться как к предыдущим (OLD), так и к текущим (NEW) значениям в предложении RETURNING для команд INSERT, UPDATE, DELETE и MERGE. Суть в том, что теперь доступны два синонима OLD и NEW, с помощью которых мы можем возвращать старые и новые значения в предложении RETURNING. Это не революционное изменение, как асинхронный ввод-вывод, но это одна из тех небольших функций, которая оказывается просто неоценимой в определённых ситуациях. Простая демонстрация с UPDATE для получения всех старых и новых значений: UPDATE fruit SET quantity = 300 WHERE item = 'Apples' RETURNING OLD.*, NEW.*; Вывод: id|item|quantity|id|item|quantity ——+—-——+————————+——+———+—————— 5|Apples| 200 | 5| Apples |300 (1 row) Получается очень просто, удобно и наглядно! Все как мы любим! ☺️ Вот еще пример. Допустим, мы выполняем операцию UPSERT (INSERT ... ON CONFLICT ... DO UPDATE) и хотим определить, была ли строка, возвращённая RETURNING, новой вставленной строкой или существующей обновлённой строкой. Это было возможно и раньше, но полагалось на неинтуитивную проверку xmax = 0: INSERT INTO webhook ( id, data ) VALUES ( @id, @data ) ON CONFLICT (id) DO UPDATE SET id = webhook.id RETURNING webhook.*, (xmax = 0) AS is_new; Этот оператор полагается на то, что xmax устанавливается в ноль для новой вставки, что является особенностью реализации блокировок в PostgreSQL. Это работает, но не является гарантированной частью API и потенциально может измениться в любой момент. В PostgreSQL 18 мы можем переписать приведённый выше код так, чтобы он был более понятным и не зависел от деталей реализации. Это также просто - достаточно проверить, является ли OLD значением NULL в предложении RETURNING: INSERT INTO webhook ( id, data ) VALUES ( @id, @data ) ON CONFLICT (id) DO UPDATE SET id = webhook.id RETURNING webhook.*, (OLD IS NULL)::boolean AS is_new; Доступ к OLD и NEW, без сомнения, найдёт множество других полезных применений, но этот пример позволяет нам сразу же улучшить код, написанный до 18-й версии. Переходим на PostgreSQL 18 и пользуемся! ☺️ #pgnews #pgbase

🌐 Выход версии PostgreSQL 18 Вчера (25.09.2025) вышла новая версия PostgreSQL! С чем всех и поздравляем 🥳 Обновление очень масштабное, порядка 3000 комитов было принято разработчиками 😳 Нововведений так много, что в пост мы смогли поместить только самый основные (на наш взгляд). Более подробно о новой версии читаем в документации: ➡️ https://www.postgresql.org/about/news/postgresql-18-released-3142/ 📌 Внедрение асинхронного ввода-вывода (AIO) Об этой крутой фиче мы уже писали. 📌 Более быстрые обновления и лучшая производительность после обновления основной версии PostgreSQL 18 представляет возможность сохранять статистику планировщика при обновлении основной версии, что помогает обновленному кластеру быстрее выйти на ожидаемый уровень производительности после обновления. Кроме того, утилита pg_upgrade включает несколько улучшений, такие как ускоренное обновление, когда база данных содержит много объектов (таблиц, последовательностей и т.д.). Этот выпуск также позволяет pg_upgrade выполнять свои проверки параллельно на основе параметра --jobs, и добавляет флаг --swap, который меняет местами каталоги обновления вместо копирования, клонирования или связывания файлов. 📌 Улучшения производительности запросов и общие улучшения Этот выпуск представляет поиск по типу "skip scan" в многоколоночных B-tree индексах, об этом мы уже писали. Также появились многочисленные улучшения в том, как PostgreSQL планирует и выполняет соединения таблиц, от повышения производительности хэш-соединений до возможности использования merge join с инкрементальными сортировками. PostgreSQL 18 также поддерживает параллельное построение GIN-индексов. 📌 Улучшение опыта разработчика PostgreSQL 18 представляет виртуальные генерируемые столбцы, которые вычисляют значения во время выполнения запроса, а не хранят их. Теперь это вариант по умолчанию для генерируемых столбцов. Кроме того, хранимые генерируемые столбцы теперь можно реплицировать логически. PostgreSQL 18 также добавляет генерацию UUIDv7 через функцию uuidv7(). 📌 Улучшенная обработка текста PostgreSQL 18 делает обработку текста проще и быстрее с помощью нескольких новых улучшений. Этот выпуск добавляет правило сортировки (collation) PG_UNICODE_FAST, которое обеспечивает полную семантику Unicode для преобразования регистра, помогая ускорить многие сравнения. 📌 Аутентификация и безопасность PostgreSQL 18 вводит аутентификацию OAUTH, которая позволяет пользователям аутентифицироваться с использованием механизмов OAuth 2.0, поддерживаемых через расширения PostgreSQL. Кроме того, PostgreSQL 18 включает проверку для режима FIPS и добавляет параметр ssl_tls13_ciphers для настройки серверных наборов шифров TLS v1.3. Аутентификация по паролю md5, объявлена устаревшей и будет удалена в будущем выпуске. Если вам требуется аутентификация на основе пароля в PostgreSQL, используйте SCRAM-аутентификацию. 📌 Репликация PostgreSQL 18 поддерживает отчетность о конфликтах записи при логической репликации в журналах и в представлении pg_stat_subscription_stats. Кроме того, CREATE SUBSCRIPTION теперь по умолчанию использует параллельное применение транзакций (parallel streaming), что может помочь повысить производительность. Утилита pg_createsubscriber теперь имеет флаг --all, позволяющий создать логические реплики для всех баз данных в экземпляре одной командой. PostgreSQL 18 также позволяет автоматически удалять бездействующие слоты репликации, чтобы предотвратить хранение слишком большого количества файлов WAL на издателе (publisher). 📌 Обслуживание и наблюдаемость PostgreSQL 18 улучшает стратегию очистки (VACUUM), проактивно замораживая больше страниц во время регулярных VACUUM-операций, снижая нагрузку и помогая в ситуациях, требующих агрессивной очистки. PostgreSQL 18 добавляет больше деталей в EXPLAIN, который предоставляет информацию о выполнении плана запроса, и, начиная с этого выпуска, теперь автоматически показывает, сколько буферов доступно при выполнении EXPLAIN ANALYZE. #pgnews

🌐 B-tree Skip Scan в PostgreSQL 18 Уже завтра должна выйти новая, 18я версия PostgreSQL! Давайте посмотрим на еще одно улучшение производительности в этой версии. Это улучшение решает давнее ограничение, когда многоколоночные B-tree индексы могли эффективно использоваться только в запросах, включающих условия равенства для ведущих (крайних слева) столбцов индекса. До PostgreSQL 18, если у вас был индекс по (region, category, date), и вы хотели выполнить запрос по category и date, не указывая region, PostgreSQL обычно прибегал к последовательному сканированию таблицы или менее эффективному сканированию индекса. Оптимизация skip scan меняет это, позволяя PostgreSQL интеллектуально "пропускать" части индекса для поиска релеватных данных, даже если ведущие столбцы пропущены в запросе. Чтобы понять важность skip scan, давайте сначала рассмотрим, как работают традиционные многоколоночные B-tree индексы и их ограничения. В предыдущих версиях PostgreSQL многоколоночные B-tree индексы были наиболее эффективны, когда запросы включали условия по ведущим столбцам. Структура индекса организует данные сначала по первому столбцу, затем по второму столбцу в пределах каждого значения первого столбца и так далее. Пример: CREATE INDEX idx_sales_region_category_date ON sales (region, category, date); -Этот запрос использует индекс эффективно: SELECT * FROM sales WHERE region = 'North' AND category = 'Electronics'; -Этот запрос не может использовать индекс эффективно (до PG18): SELECT * FROM sales WHERE category = 'Electronics' AND date > '2025-01-01'; Второй запрос выше традиционно требовал от PostgreSQL сканировать все записи индекса или возвращаться к последовательному сканированию таблицы, поскольку он не указывает ведущий столбец region. Skip scan решает эту проблему, позволяя PostgreSQL эффективно ориентироваться в структуре индекса, даже если ведущие столбцы отсутствуют в запросе. Это достигается за счет идентификации различных значений в неуказанных ведущих столбцах и выполнения целевого сканирования для каждого значения. Оптимизация skip scan наиболее эффективна когда ведущие столбцы будут с низкой кардинальностью. Т. е. Skip scan работает лучше всего, когда пропущенные ведущие столбцы имеют относительно немного уникальных значений. Оптимизация работает, по сути, выполняя отдельные сканирования индекса для каждого уникального значения в пропущенных ведущих столбцах, поэтому меньше уникальных значений означает меньше отдельных сканирований. Хотя skip scan значительно улучшает производительность запросов во многих сценариях, важно понимать его характеристики и ограничения. Skip scan полезен не во всех ситуациях: ❌ Ведущие столбцы с высокой кардинальностью. Когда ведущий столбец имеет слишком много уникальных значений, skip scan становится неэффективным; ❌ Большие результирующие наборы. Когда ваш запрос возвращает большую часть таблицы, последовательное сканирование обычно быстрее. Планировщик запросов PostgreSQL автоматически определяет, когда skip scan целесообразен, на основе статистики таблицы и оценок стоимости. Вам не нужно вручную настраивать, когда его использовать - планировщик выбирает наиболее эффективный подход для каждого запроса. Поддерживайте актуальность статистики таблиц, чтобы обеспечить принятие планировщиком хороших решений об использовании skip scan. Свежая статистика помогает PostgreSQL точно оценивать кардинальность столбцов индекса и принимать оптимальные решения по использованию skip scan. Ограничения Skip scan в PostgreSQL 18 имеет определенную область применения: 📌 Работает только с индексами типа B-tree; 📌 Наиболее эффективен, когда пропущенные ведущие столбцы имеют низкую кардинальность; 📌 Требует по крайней мере одно условие равенства для последующего столбца в индексе; 📌 Преимущество в производительности уменьшается по мере роста количества уникальных значений в пропущенных столбцах. Ждем PostgreSQL 18 с нетерпением! 😁 #pgnews

🤬 Разбираемся с ошибкой «database is not accepting commands». Если вы столкнулись с этой ошибкой, то это говорит о том, что ваша PostgreSQL находится очень близко к transaction ID wraparound 😱. В этом состоянии вы все еще можете выполнять запросы на чтение, но не можете производить какие-либо изменения данных. Чтобы довести PostgreSQL до такого состояния, нужно очень постараться, так как у СУБД есть защитные меры для предотвращения transaction ID wraparound: ✅ Если в таблице есть активные строки, возраст которых превышает autovacuum_freeze_max_age транзакций (по умолчанию 200 миллионов), PostgreSQL запустит анти-зацикливающий (anti-wraparound) autovacuum worker; ✅ Если в таблице есть активные строки, возраст которых превышает vacuum_failsafe_age транзакций (по умолчанию 1,6 миллиарда) PostgreSQL запустит экстренный анти-зацикливающий autovacuum worker, который пропускает этап очистки индексов и работает так быстро, как только может; ✅ За 40 миллионов транзакций до переполнения (wraparound) идентификатора транзакции (XID) в журнале (log) появятся предупреждения. Только если ни одна из этих защитных мер не может предотвратить проблему, PostgreSQL остановит внесение изменений в базу данных. Есть несколько способов помешать PostgreSQL самостоятельно решить проблему 😅: ❌ Держать транзакцию в базе данных открытой вечно; ❌ Держать подготовленную транзакцию (prepared transaction), не подтверждая и не откатывая ее; ❌ Иметь «заброшенный» слот репликации (orphaned replication slot), при этом на standby-сервере включена опция hot_standby_feedback; ❌ Если есть в базе повреждение данных, из-за которого операция VACUUM завершается с ошибкой. Каков правильный способ устранения ошибки «database is not accepting commands»? На самом деле, все описано в документации, которую все же иногда бывает полезно почитать 😅. ⚠️Обратите внимание: в отличие от того, что иногда рекомендовалось в более ранних версиях, нет необходимости и нежелательно останавливать postmaster или переходить в однопользовательский режим (single-user mode), чтобы восстановить нормальную работу. Вместо этого выполните следующие действия: 1️⃣ Завершите старые подготовленные транзакции. Вы можете найти их, проверив представление pg_prepared_xacts на наличие строк, где age(transactionid) велик. Такие транзакции следует зафиксировать (commit) или откатить (rollback); 2️⃣ Завершите длительные открытые транзакции. Вы можете найти их, проверив представление pg_stat_activity на наличие строк, где age(backend_xid) или age(backend_xmin) велик. Такие транзакции следует зафиксировать, откатить, или сеанс можно завершить с помощью pg_terminate_backend; 3️⃣ Удалите все старые слоты репликации. Используйте pg_stat_replication, чтобы найти слоты, где age(xmin) или age(catalog_xmin) велик. Во многих случаях такие слоты были созданы для репликации на серверы, которые больше не существуют или отключены в течение длительного времени. ⚠️ Если вы удалите слот для сервера, который все еще существует и может попытаться подключиться к этому слоту, эту реплику, возможно, придется пересоздать; 4️⃣ Выполните VACUUM в целевой базе данных. Проще всего выполнить VACUUM для всей базы данных, чтобы сократить время, также можно вручную выполнить команды VACUUM для таблиц с самым старым relminxid. Что НЕ нужно делать: ❌ Не запускайте PostgreSQL в однопользовательском режиме, это усложнит восстановление и увеличит время простоя; ❌ Не запускайте VACUUM (FULL). Многие считают, что это лекарство от всех проблем, но он выполняет гораздо больше работы, чем обычный VACUUM, и это опять приведет к гораздо более длительному простою; ❌ Не запускайте VACUUM (FREEZE). Он «замораживает» все строки таблицы. Это больше работы, чем необходимо, и приведет к увеличению времени простоя. Резюмируя, можно сказать, что в такой ситуации нужно завершить все транзакции и запустить ОБЫЧНЫЙ VACUUM. Ну и это.... не забывайте читать документацию хоть иногда 😁. #pgerror

Не пропустите! 24 сентября в 20:00 пройдет бесплатный урок “Маленькие хитрости GROUP BY” от онлайн-курса “PostgreSQL для администраторов баз данных и разработчиков”. Группировка строк с использованием GROUP BY - один из самых мощных инструментов в арсенале аналитиков и разработчиков. Узнайте теоретические основы и практические возможности этого инструмента на открытом уроке. Что вас ждет на вебинаре: - Вспомним, как устроен GROUP BY, и рассмотрим его на наглядных примерах - Оптимизируем работу группировки в связке с индексами - Разберемся с особенностями группировки строк в PostgreSQL - Изучим несколько полезных приемов для работы с GROUP BY Что будет на уроке: - Разберём логику работы GROUP BY и типичные ошибки, которые тормозят запросы - Оптимизация группировки с помощью индексов — когда она действительно работает - Специфика GROUP BY в PostgreSQL: что можно, а что лучше не делать - Несколько приёмов, которые ускорят и упростят обработку больших наборов данных Результат участия: - Поймёте, как извлекать максимум из GROUP BY в PostgreSQL - Сможете оптимизировать работу запросов с большими объёмами данных - Получите набор трюков, которые можно применять прямо в продакшене Успейте записаться на урок: https://otus.pw/uwio/?erid=2W5zFK3zzHN Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🤖 Оператор SIMILAR TO в PostgreSQL SIMILAR TO — это оператор поиска по шаблону, который сочетает в себе интуитивно понятный синтаксис LIKE с мощью регулярных выражений. Он возвращает true, если строка полностью соответствует заданному шаблону, и false в противном случае. Это его ключевое отличие от LIKE: шаблон должен описывать всю строку, а не просто входить в нее. Базовый синтаксис: строка SIMILAR TO шаблон [ESCAPE 'escape-символ']; Зачем он нужен? Представьте ситуацию: вам нужно найти номера телефонов в формате (XXX) XXX-XXXX. С LIKE это возможно, но запрос получится очень громоздким и нечитаемым: вам пришлось бы использовать несколько LIKE с OR и точно считать количество символов. Полноценное регулярное выражение с оператором ~ справится с этим, но его синтаксис может показаться сложным для простых задач. SIMILAR TO идеально подходит для таких "промежуточных" случаев, предлагая более выразительный способ описания шаблона, чем LIKE, но не такой сложный, как полноценные регулярные выражения. Арсенал метасимволов у SIMILAR TO гораздо больше, чем у LIKE: % - любая последовательность из нуля или более символов; _ - любой одиночный символ; \| Выбор (OR) - указывает альтернативные варианты шаблона; * - повторение предыдущего элемента нуль или более раз; + - повторение предыдущего элемента один или более раз; ? - повторение предыдущего элемента нуль или один раз; {m} - повторение предыдущего элемента ровно m раз; {m,} - повторение предыдущего элемента m или более раз; {m,n} - повторение предыдущего элемента не менее m и не более n раз; [...] - список символов (как в [abc]) или диапазон (как в [a-z]). Совпадает с любым одним символом из списка; [^...] - отрицательный список символов. Совпадает с любым одним символом, которого нет в списке; () - группировка элементов. Важное примечание: Поскольку эти метасимволы являются частью синтаксиса SQL, обратная косая черта \ НЕ является экранирующим символом по умолчанию. Чтобы использовать литеральные версии этих символов в шаблоне (например, найти сам знак %), их нужно экранировать с помощью предложения ESCAPE. Примеры; Допустим, у нас есть таблица products с полем name. 1️⃣ Простой поиск (как в LIKE): - Найти товары, название которых начинается на 'Про': SELECT name FROM products WHERE name SIMILAR TO 'Про%'; 2️⃣ Использование выбора (|): - Найти товары, либо 'стол', либо 'стул': SELECT name FROM products WHERE name SIMILAR TO 'стол|стул'; 3️⃣ Проверка сложного формата: - Найти номера телефонов в формате +7(XXX)XXX-XX-XX: SELECT phone FROM users WHERE phone SIMILAR TO '\+7\(___\)___-__-__'; Здесь мы используем _ для обозначения любого цифрового символа и экранируем литеральные скобки \( и \), а также знак \+ с помощью обратной косой черты. 4️⃣ Использование повторов и диапазонов: - Найти коды товаров, которые состоят из 3-5 цифр, а затем одной или двух букв: SELECT code FROM products WHERE code SIMILAR TO '[0-9]{3,5}[A-Z]{1,2}'; Главный недостаток SIMILAR TO — это его производительность. Он реализован поверх механизма регулярных выражений, но менее эффективен, чем как нативный LIKE, так и часто даже операторы ~. Когда использовать SIMILAR TO? ✅ Используйте LIKE для простейшего поиска подстрок. Это самый быстрый и стандартный вариант; ✅ Используйте SIMILAR TO в исключительных случаях, когда шаблон слишком сложен для LIKE (требует повторов, выбора или групп), но вам критически важно, чтобы шаблон описывал всю строку, и вы не хотите разбираться с полным синтаксисом регулярных выражений; ✅ Используйте операторы ~ (регулярные выражения) для самых сложных и гибких задач поиска, когда мощь SIMILAR TO уже недостаточна, или когда вам нужно искать не полное совпадение, а подстроку. В большинстве реальных сценариев LIKE и полноценные регулярные выражения ~ покрывают все потребности. SIMILAR TO остается нишевым оператором, полезным в специфических ситуациях, но его стоит иметь в виду как еще один инструмент в вашем арсенале SQL. На этом все! До связи! #queries

🔍 Операторы LIKE и ILIKE в PostgreSQL. Всем привет! Сегодня поговорим про операторы LIKE и ILIKE. Они не так могущественны, как регулярные выражения, но зато невероятно просты, понятны и часто - гораздо быстрее. Это операторы, которые проверяют, соответствует ли строка заданному шаблону. Их главная сила - в использовании двух специальных символов: % (знак процента): Обозначает последовательность из любого количества любых символов (включая ноль символов). Примеры: a% - что угодно, начинающееся на 'a'; %a - что угодно, заканчивающееся на 'a'; %a% - что угодно, содержащее 'a' в любой части. _ (нижнее подчёркивание): Обозначает ровно один любой символ. Примеры: a_ - начинается на 'a' и имеет ровно один символ; _a - заканчивается на 'a' и имеет ровно один символ; a__b - начинается на 'a', заканчивается на 'b' и имеет ровно 2 символа. В чём разница между LIKE и ILIKE? LIKE — чувствителен к регистру. 'A' и 'a' для него разные вещи. ILIKE (PostgreSQL-specific!) — НЕ чувствителен к регистру. 'A' и 'a' для него одно и то же. Важно: ILIKE — это уникальное расширение PostgreSQL. В стандарте SQL его нет, поэтому на других СУБД (например, MySQL или MS SQL) используйте LIKE с функциями для приведения регистра (например, LOWER()). 🛠️ Примеры из жизни Допустим, у нас есть таблица users с полем name: Найти всех users с именем, которое начинается на "Анн": SELECT * FROM users WHERE name LIKE 'Анн%'; Найти всех, у кого в имени есть "маш": SELECT * FROM users WHERE name ILIKE '%маш%'; -- ILIKE найдет и "Маша", и "МАША" Найти пользователей с именами из 5 букв, которые начинаются на "А" и заканчиваются на "й": SELECT * FROM users WHERE name LIKE 'А_____й'; Найти товары с артикулом, по маске: 123-любой_текст-456: SELECT * FROM products WHERE article LIKE '123-%-456'; Найти все email в домене yandex (без учета регистра): SELECT * FROM users WHERE email ILIKE '%@yandex.ru'; 💡 Советы и лучшие практики 1️⃣ Производительность: Запросы с LIKE могут быть медленными, если шаблон начинается с % (например, '%abc'), потому что СУБД не может использовать обычный индекс (ей придётся сканировать всю таблицу — seq scan). Для таких запросов лучше подходят GIN-индексы с опцией gin_trgm_ops (триграммные индексы), которые PostgreSQL умеет использовать для поиска по подстроке; 2️⃣ Экранирование: Если вам нужно найти сам символ % или _, его нужно экранировать с помощью символа \ (обратный слеш) или указав другой escape-символ с помощью конструкции ESCAPE. Найти значения, содержащие символ "_": SELECT * FROM table WHERE name LIKE '%\_%' ESCAPE '\'; 3️⃣ Когда что использовать? LIKE/ILIKE — ваш выбор, когда шаблон простой: поиск по началу, концу строки или наличию подстроки. Регулярные выражения - берите в бой, когда шаблон сложный: "найти все слова, начинающиеся на гласную, затем идущие 3 цифры, а потом знак препинания", например; 4️⃣ Читаемость: Запрос с LIKE 'ABC%' всегда будет более читаемым и очевидным для другого разработчика, чем его аналог с регулярным выражением ~ '^ABC'. Вывод: LIKE и ILIKE - это простые и эффективные инструменты для 80% задач по поиску текста. Не забывайте о них, прежде чем брать в руки тяжёлую артиллерию регулярных выражений. О регулярках в PostgreSQL мы поговорим в будущих постах. На этом все! До связи! #pgbase #queries

🤖 Команда DO в PL/pgSQL Всем привет! Давно у нас ничего не было по PL/pgSQL. Исправляемся! 😊 Команда DO - это средство для выполнения анонимных блоков кода на языке PL/pgSQL (и не только) непосредственно в PostgreSQL без необходимости создания именованной функции или процедуры. Синтаксис: DO [ LANGUAGE lang_name ] $$ DECLARE -- объявление переменных (опционально) BEGIN -- исполняемый код END; $$; Здесь lang_name необходим в том случае, если вы используете язык программирования, отличный от PL/pgSQL. Язык должен быть установлен в PostgreSQL. Основные характеристики команды: 1️⃣ Анонимность. Блок кода не сохраняется в базе данных и выполняется только один раз при вызове. 2️⃣ Одноразовое выполнение. Идеально для разовых задач, миграций, тестирования. 3️⃣ Не принимает параметры. В отличие от функций, не может принимать входные параметры. 4️⃣ Не возвращает результат (void). Простой пример: DO $$ BEGIN RAISE NOTICE 'Текущее время: %', NOW(); END; $$; Пример с объявлением переменных: DO $$ DECLARE user_count INTEGER; avg_id NUMERIC; BEGIN SELECT COUNT(*) INTO user_count FROM users; RAISE NOTICE 'Количество пользователей: %', user_count; END; $$; Практическое использование. 1️⃣ Массовое обновление данных: DO $$ BEGIN UPDATE products SET price = price * 1.1 WHERE category_id = 5; RAISE NOTICE 'Цены обновлены для категории 5'; END; $$; 3️⃣ Валидация данных: DO $$ DECLARE invalid_records INTEGER; BEGIN SELECT COUNT(*) INTO invalid_records FROM orders WHERE order_date > CURRENT_DATE; IF invalid_records > 0 THEN RAISE EXCEPTION 'Найдено % записей с будущей датой заказа', invalid_records; END IF; END; $$; 3️⃣ Сложная логика с обработкой ошибок: DO $$ BEGIN BEGIN INSERT INTO audit_log (action, table_name, user_id) VALUES ('UPDATE', 'products', current_user); UPDATE products SET last_updated = NOW(); RAISE NOTICE 'Операция выполнена успешно'; EXCEPTION WHEN others THEN RAISE NOTICE 'Произошла ошибка: %', SQLERRM; ROLLBACK; END; END; $$; Особенности и ограничения: 1️⃣ Нельзя использовать в выражениях. В отличие от функций, результат DO нельзя использовать в SELECT; 2️⃣ Нет возвращаемого значения. 3️⃣ Временное существование. Код выполняется и сразу "забывается" сервером. 4️⃣ Поддержка транзакций. Весь блок выполняется в одной транзакции, если не указано иное. Best Practices: ✅ Используйте для разовых операций; ✅ Для сложной логики, требующей повторного использования, создавайте функции; ✅ Всегда обрабатывайте возможные исключения; ✅ Используйте RAISE NOTICE для отладки; ✅ Для длительных операций добавляйте индикацию прогресса. На этом все! До связи! #pl/pgsql