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

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

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

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».)