DEV1-12. 16. Обработка ошибок

[@maximsmolin8111]

А самого главного то и не показали, как отлавливать ошибки и делать ROLLBACK

[@maximsmolin8111]

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

[@PostgresProfessional]

GET CURRENT DIAGNOSTICS

[@maximsmolin8111]

INSERT on CONFLICT очень похож на MERGE из стандарта SQL. Реализован ли MERGE в Postres?

[@PostgresProfessional]

Нет. Про историю вопроса: habr.com/en/company/postgrespro/blog/412605/

[@maximsmolin8111]

А что будет, если я сделаю переменные с именами no_data_found или too_many_rows? Просто пугает вероятность того, что в будущем твоя переменная может внезапно войти в вокабуляр Postrges и программа перестанет работать.

[@PostgresProfessional]

Это разные пространства имен. У вас могут быть переменные с такими именами, и это ничему не мешает.

[@maximsmolin8111]

Печально. Такое поведение было в MS SQL до версии 2005, когда после каждого оператора нужно было использовать обработку IF @@ERROR 0 . Но когда в 2005 году появилась конструкция TRY..CATCH жить стало намного легче, так как любые ошибки приводили в секцию CATCH, где можно было делать единую обработку и ROLLBACK. Поведение Postgres отстает от современного уровня на 16 лет. Надеюсь, в следующих версиях это допилят.

[@PostgresProfessional]

А чем вам EXCEPTION не CATCH?

[@maximsmolin8111]

@@PostgresProfessional в catch можно делать rollback, или не делать в случае "бизнес ошибок", а выполнить, например, другой "исправляющий" код. На PGConf2021 пообщался с Егором Роговым и он предложил выход - в блоке exception взводить флаг, по которому в дальнейшем делать/не делать rollback.