Мені дуже подобається роз'яснення цієї функції Крейга. Спеціалізація SQL-2011 визначає їх у контексті тригера як "колекцію рядків, що видаляються, вставляються або замінюються, відома як таблиця переходу". Аналогічне пояснення надається в документації,
У той час як таблиці переходів для AFTER
тригерів задаються REFERENCING
стандартним способом, використовуючи параметр, змінні рядків, що використовуються в FOR EACH ROW
тригерах, не можуть бути вказані в REFERENCING
пункті. Вони доступні способом, який залежить від мови, якою написана тригерна функція. Деякі мови ефективно поводяться так, ніби є REFERENCING
пункт, що міститьOLD ROW AS OLD NEW ROW AS NEW.
По суті, вони роблять доступними ці зміни у заяві, що дуже зручно. Для довідки, тригер DDL при створенні виглядає так з таблицями переходів
REFERENCING OLD TABLE AS oldtable NEW TABLE AS newtable
Ви можете побачити приклад тут , і ось один із тестового набору ,
CREATE TABLE transition_table_base (id int PRIMARY KEY, val text);
CREATE FUNCTION transition_table_base_ins_func()
RETURNS trigger
LANGUAGE plpgsql
AS $$
DECLARE
t text;
l text;
BEGIN
t = '';
FOR l IN EXECUTE
$q$
EXPLAIN (TIMING off, COSTS off, VERBOSE on)
SELECT * FROM newtable
$q$ LOOP
t = t || l || E'\n';
END LOOP;
RAISE INFO '%', t;
RETURN new;
END;
$$;
CREATE TRIGGER transition_table_base_ins_trig
AFTER INSERT ON transition_table_base
REFERENCING OLD TABLE AS oldtable NEW TABLE AS newtable
FOR EACH STATEMENT
EXECUTE PROCEDURE transition_table_base_ins_func();
Деякі додаткові замітки
- Вони доступні лише на
AFTER
пускових механізмах.
- Вони враховують такі речі
ON CONFLICT
.
Важливо зазначити, що в PG 10 це не зовсім впевнено . З таблицями переходу існує багато відкритих питань . Більшість мають патчі. Є певна боротьба, яка є своєрідною рутиною. Здається, важкий підйом підхопив хтось інший. Нитка вказує на те, що ми будемо знати в найближчим часом .
Автор відповів - здається, знову буде добре.