Мне очень нравится объяснение Крейга этой функции. Спецификация 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 . Есть много открытых вопросов с таблицами переходов . У большинства есть патчи. Есть некоторая борьба, которая является своего рода рутиной. Кажется, тяжелый подъем был поднят кем-то еще. Нить указывает на то, что мы будем знать в ближайшее время .
Автор ответил - похоже, снова идет хорошо.