虽然触发器的许多用途都涉及用户编写的触发器函数， 但 PostgreSQL 提供了几个内置的触发器函数， 它们可以直接用在用户定义的触发器中。 它们被总结在 Table 9.110 中。 （还存在额外的内置触发器函数， 它们实现外键约束和延迟索引约束。 这里不记录那些， 因为用户不需要直接使用它们。）
有关创建触发器的更多信息， 请参见 CREATE TRIGGER。
Table 9.110. 内建触发器函数
函数 说明 用法示例 |
|---|
抑制不做事的更新操作。 细节见下文。
|
根据关联的纯文本文档列自动更新一个
|
根据关联的纯文本文档列自动更新一个
|
当
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” 前缀的由来。）