Хотел спросить, говорили ли вы с коллегами по поводу INSTEAD OF DELETE триггера. Что когда в нём изменяем OLD, то изменйнные данные не становятся входом для следующего триггера. Несмотря на то, что в доке сказано:
In the case of BEFORE and INSTEAD OF triggers, the possibly-modified row returned by each trigger becomes the input to the next trigger
https://www.postgresql.org/docs/current/trigger-definition.html
Пример: https://dbfiddle.uk/?rdbms=postgres_12&fiddle=e875ac4e510681d9fc08fddf4f1374d1
Добрый день! Нет, не говорил. Я же Вам писал, кажется — Ваш прошлый пример был просто слишком большим (и, видно, кончилось tl;dr). :( Да и вообще, лично мне поход стандарта к (bi)temporal не нравится, поэтому помогать внедрять его в PostgreSQL совершенно не хочется. А по поводу примера — в доке также сказано: A row-level INSTEAD OF trigger should either return NULL to indicate that it did not modify any data from the view's underlying base tables, or it should return the view row that was passed in (the NEW row for INSERT and UPDATE operations, or the OLD row for DELETE operations). For INSERT and UPDATE operations, the trigger may modify the NEW row before returning it. This will change the data returned by INSERT RETURNING or UPDATE RETURNING, and is useful when the view will not show exactly the same data that was provided. Т.е. максимум, чего тут можно добиться, как мне кажется — изменения документации, чтобы было понятнее написано.
Обсуждают сегодня