虽然 PostgreSQL 触发器的大多数用途都涉及用户编写的触发器函数，但它提供了一些可以直接在用户自定义触发器中使用的内置触发器函数。这些函数的信息总结在 表 9.107 中。（还存在其他内置触发器函数，它们用于实现外键约束和延迟索引约束。这里并未对此文档说明，因为用户无需直接使用这些函数。）
关于创建触发器的更多信息，请参阅 CREATE TRIGGER。
表 9.107. 内置触发器函数
|
函数 描述 示例用法 |
|---|
|
禁止不执行任何操作的更新操作。如下详细介绍。
|
|
从相关纯文本文档列自动更新
|
|
从相关纯文本文档列自动更新
|
如果 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”。）