Триггерные функции

Хотя в большинстве случаев использование триггеров предусматривает триггерные функции, написанные пользователем, QHB предоставляет несколько встроенных триггерных функций, которые можно использовать непосредственно в пользовательских триггерах. Эти функции перечислены в Таблице 100. (Существуют и другие встроенные триггерные функции, реализующие ограничения внешнего ключа и отложенные индексные ограничения. Они здесь не приводятся, поскольку пользователям не нужно применять их напрямую.)

Подробную информацию о создании триггеров см. на справочной странице команды CREATE TRIGGER.

Таблица 100. Встроенные триггерные функции

Функция
	Описание Пример использования
suppress_redundant_updates_trigger ( ) → trigger
	Подавляет фиктивные операции изменения. Подробную информацию см. ниже. CREATE TRIGGER ... suppress_redundant_updates_trigger()
tsvector_update_trigger ( ) → trigger
	Автоматически обновляет столбец tsvector из связанных столбцов с обычными текстовыми данными. Используемая конфигурация текстового поиска задается по имени в аргументе триггера. Подробную информацию см. в подразделе Триггеры для автоматических обновлений. CREATE TRIGGER ... tsvector_update_trigger(tsvcol, 'pg_catalog.swedish', title, body)
tsvector_update_trigger_column ( ) → trigger
	Автоматически обновляет столбец tsvector из связанных столбцов с обычными текстовыми данными. Используемая конфигурация текстового поиска берется из столбца regconfig целевой таблицы. Подробную информацию см. в подразделе Триггеры для автоматических обновлений. CREATE TRIGGER ... tsvector_update_trigger_column(tsvcol, tsconfigcol, title, body)

Функция suppress_redundant_updates_trigger, применяемая в качестве триггера BEFORE UPDATE на уровне строк, предотвратит внесение любых изменений, при которых данные в строке фактически не меняются. Это переопределяет обычное поведение, когда изменение физической сроки происходит всегда, независимо от того, были ли изменены данные. (Обычное поведение ускоряет выполнение изменений, поскольку при этом не требуется сравнение данных, и в некоторых случаях это может быть полезно.)

В идеале следует избегать выполнения изменений, которые фактически не меняют данные в записи. На лишние изменения может уйти довольно много времени, особенно если требуется обновить множество индексов, а также пространства в неиспользуемых строках, от которых в итоге придется чистить базу данных. Однако выявить подобные ситуации в коде клиента не всегда просто или даже возможно, а при написании выражений для их обнаружения легко допустить ошибку. В качестве альтернативы можно использовать функцию suppress_redundant_updates_trigger, которая будет пропускать изменения, не меняющие данные. Однако пользоваться ей следует с осторожностью. Выполнение этого триггера для каждой записи происходит довольно быстро, но не мгновенно, поэтому если большинство затронутых изменениями записей действительно меняется, использование этого триггера в среднем замедлит операции изменения.

Функцию suppress_redundant_updates_trigger можно добавить к таблице следующим образом:

CREATE TRIGGER z_min_update
BEFORE UPDATE ON tablename
FOR EACH ROW EXECUTE FUNCTION suppress_redundant_updates_trigger();

В большинстве случаев этот триггер необходимо запускать для каждой строки последним, чтобы он не переопределил другие триггеры, которым может потребоваться изменить строку. Учитывая то, что триггеры запускаются в порядке сортировки имен, имя этого триггера следует выбрать так, чтобы оно шло после имен всех остальных триггеров, которые могут быть в таблице. (Поэтому в примере используется префикс «z».)