PostgreSQL RETURNING: как получить изменённые строки без отдельного SELECT

PostgreSQL RETURNING: как получить изменённые строки без отдельного SELECT
Содержание статьи

UPDATE ... RETURNING позволяет получить новые значения изменённых строк в ответе того же запроса. Отдельный SELECT для этого не нужен. На Mentoring.digital разберём учебный сценарий и случай, когда обновление не нашло ни одной строки.

Какую задачу решает RETURNING

Представьте обработчик, который переводит заявку из состояния new в processing. Клиенту нужно вернуть её идентификатор и новое состояние. Если сначала выполнить UPDATE, а потом отдельно читать таблицу, придётся поддерживать связь между двумя действиями.

RETURNING привязывает возвращаемые данные к строкам, которые изменил именно этот оператор. Но он не проверяет права пользователя и не создаёт за вас бизнес-правило допустимого перехода. Эти условия должны присутствовать в логике приложения и запросе.

Самодостаточный учебный пример

BEGIN;
CREATE TEMP TABLE requests_demo (
    id integer PRIMARY KEY,
    status text NOT NULL
);
INSERT INTO requests_demo VALUES (1, 'new'), (2, 'done');

UPDATE requests_demo
SET status = 'processing'
WHERE id = 1 AND status = 'new'
RETURNING id, status;

ROLLBACK;

Ожидаемая возвращаемая строка содержит 1 и processing. Временная таблица нужна, чтобы пример не обращался к рабочим данным. ROLLBACK отменяет изменения транзакции. Это образец для отдельного тестового подключения, а не команда для производственной базы.

Драйвер приложения должен прочитать набор результата, а не только сообщить, что SQL выполнен. Проверьте, какое значение возвращает используемая библиотека и как она представляет отсутствие строк.

Что означает пустой результат

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

Пустой набор может соответствовать нескольким причинам: идентификатор не существует либо заявка уже в другом состоянии. Выберите ответ API осознанно. Для некоторых операций важно различать эти причины, для других раскрывать существование записи не следует. SQL сам не выбирает нужный вариант ответа клиенту.

Какие поля возвращать

Укажите нужные колонки явно. RETURNING * удобно для исследования таблицы, но публичный ответ приложения лучше не связывать со всеми её столбцами. Новое поле в схеме не должно случайно становиться частью ответа.

Для UPDATE обычные имена полей в RETURNING относятся к новым значениям. Официальная документация также описывает возврат данных для INSERT и DELETE. Перед использованием более новой специальной формы синтаксиса сверяйте её с версией своего сервера, а не только с текущей страницей документации.

Что включить в тест

  • Подходящая строка меняется и возвращается с нужными полями.
  • Несуществующий ID даёт пустой набор.
  • Недопустимое исходное состояние не проходит условие.
  • Ошибка SQL не маскируется под обычное отсутствие строки.

Не составляйте SQL конкатенацией пользовательского значения: передавайте параметры средствами драйвера. Проработать запрос и обработку результата можно с наставником по SQL. Здесь приведён ожидаемый результат; выполнение на PostgreSQL в редакционной среде не заявляется.

Похожие статьи по данной теме