Hello, sasha!
sasha wrote:
Нет нет нет и нет. Это на самом деле не так. Я вам уже писал - повесьте
триггер на AFTER и он отменит операцию.
потому что навешивание триггеров (любых) отменяет обновление
автообновляемого view.
Исходя из этого почему я могу сделать в триггере BEFORE
INSERT INTO TABLE ... RETURNING ID INTO NEW.ID
а в триггере AFTER не могу. Повторяю, они оба отменяют стандартное
поведение, оба!!!
потому что в after уже поздно чего-либо менять.
т.е., есть два правила:
1. навешивание любого триггера перестает обновлять автообновляемое view
2. в триггерах after (вообще) нельзя менять new/old
рисуем таблицу соответствия. И - тебе не нравится, что триггер
after на view и отменяет обновление и не дает изменить? Ну,
ты попал. Если бы ты писал триггеры на таблицы, а не на view,
то тебя бы это не удивило.
Поэтому, в соответствии с нормальной логикой, а не твоей,
нужно было бы просить фичу
- не отменять обновление у view при создании after-триггеров.
И ВСЕ. И никаких instead of, new в after и так далее.
я еще раз объясняю. что фактически все это работает именно так
уже примерно 15 лет, как минимум.
Недавно менялось с отменой автоматического действия.
так ВСЕГДА было написано в документации. Поведение
сервера документации не соответствовало.
Да не синоним это. Это другой вид триггера. Его отличительная
особенность в том что:
нет в IB/FB "других видов триггеров".
Ничё я не запутался. Я всё прекрасно понимаю как оно работает.
да ну?
Зачем менять - потому что оно концептуально неправильно сделано.
возвращаемся обратно на 15 лет назад.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
