我是靠谱客的博主 舒适音响,最近开发中收集的这篇文章主要介绍触发器,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

1. 触发器行为概述

 

一个触发器函数可以再一个INSERTUPDATE, 或者 DELETE 命令之前或者之后执行,要么是对每个被修改的行一次, 要么是每条 SQL 一次。 如果发生触发器事件,那么将在合适的时刻调用触发器的函数以处理该事件。

触发器函数必须在创建触发器之前,作为一个没有参数并且返回trigger类型的函数定义。 (触发器函数通过特殊的 TriggerData 结构接收其输入,而不是用普通函数参数那种形式。)

一旦创建了一个合适的触发器函数,触发器就用 CREATE TRIGGER 创建。同一个触发器函数可以用于多个触发器。

有两种类型的触发器:按行触发的触发器和按语句触发的触发器。在按行触发的触发器里, 触发器函数是为触发触发器的语句影响的每一行执行一次。相比之下,一个按语句触发的触发器是在每执行一次合适的语句执行一次的, 而不管影响的行数。特别是,一个影响零行的语句将仍然导致任何适用的按语句触发的触发器的执行。 这两种类型的触发器有时候分别叫做"行级别的触发器""语句级别的触发器"

语句级别的 "before" 触发器通常在语句开始做任何事情之前触发, 而语句级别的 "after" 触发器在语句的最后触发。 行级别的 "before" 触发器在对特定行进行操作的时候马上触发, 而行级别的 "after" 触发器在语句结束的时候触发(但是在任何语句级别的 "after" 触发器之前)。

按语句触发的触发器应该总是返回 NULL。 如果必要,按行触发的触发器函数可以给调用它的执行者返回一表数据行(一个类型为 HeapTuple 的数值), 那些在操作之前触发的触发器有以下选择:

 

 

  • 它可以返回 NULL 以忽略对当前行的操作。 这就指示执行器不要执行调用该触发器的行级别操作(对特定行的插入或者更改))。

  • 只用于INSERTUPDATE触发器: 返回的行将成为被插入的行或者是成为将要更新的行。 这样就允许触发器函数修改被插入或者更新的行。

一个无意导致任何这类行为的在操作之前触发的行级触发器必须仔细返回那个被当作新行传进来的同一行 (也就是说,对于 INSERTUPDATE 触发器而言,是 NEW 行, 对于 DELETE 触发器而言,是 OLD 行)。

对于在操作之后触发的行级别的触发器,其返回值会被忽略,因此他们可以返回NULL

如果多于一个触发器为同样的事件定义在同样的关系上, 触发器将按照由名字的字母顺序排序的顺序触发。 如果是事件之前触发的触发器,每个触发器返回的可能已经被修改过的行成为下一个触发器的输入。 如果任何事件之前触发的触发器返回 NULL 指针, 那么其操作被丢弃并且随后的触发器不会被触发。

通常,行的 before 触发器用于检查或修改将要插入或者更新的数据。 比如,一个 before 触发器可以用于把当前时间插入一个时间戳字段, 或者跟踪该行的两个元素是一致的。行的 after 触发器多数用于填充或者更新其它表, 或者对其它表进行一致性检查。这么区分工作的原因是, after 触发器肯定可以看到该行的最后数值, 而 before 触发器不能;还可能有其它的 before 触发器在其后触发。 如果你没有具体的原因定义触发器是 before 还是 after,那么 before 触发器的效率高些, 因为操作相关的信息不必保存到语句的结尾。

如果一个触发器函数执行 SQL 命令,然后这些命令可能再次触发触发器。 这就是所谓的级联触发器。对级联触发器的级联深度没有明确的限制。 有可能出现级联触发器导致同一个触发器的递归调用的情况; 比如,一个 INSERT 触发器可能执行一个命令, 把一个额外的行插入同一个表中,导致 INSERT 触发器再次激发。 避免这样的无穷递归的问题是触发器程序员的责任。

在定义一个触发器的时候,我们可以声明一些参数。 在触发器定义里面包含参数的目的是允许类似需求的不同触发器调用同一个函数。 比如,我们可能有一个通用的触发器函数, 接受两个字段名字,把当前用户放在第一个,而当前时间戳在第二个。 只要我们写得恰当,那么这个触发器函数就可以和触发它的特定表无关。 这样同一个函数就可以用于有着合适字段的任何表的 INSERT 事件,实现自动跟踪交易表中的记录创建之类的问题。如果定义成一个 UPDATE 触发器,我们还可以用它跟踪最后更新的事件。

每种支持触发器的编程语言都有自己的方法让触发器函数得到输入数据。 这些输入数据包括触发器事件的类型(比如,INSERT 或者 UPDATE)以及所有在 CREATE TRIGGER 里面列出的参数。 对于低层次的触发器,输入数据也包括 INSERTUPDATE 触发器的 NEW 行,和/或 UPDATEDELETE 触发器的 OLD 行。 语句级别的触发器目前没有任何方法检查改语句修改的独立行。

 

2. 数据改变的可视性

如果你在你的触发器函数里执行 SQL 命令,并且这些命令访问触发器所在的表, 那么你必须知道触发器的可视性规则,因为这些规则决定这些 SQL 命令是否能看到触发触发器的数据改变。 简单说:

 

 

  • 语句级别的触发器遵循简单的可视性原则:在语句之前(before)触发的触发器看不到所有语句做的修改, 而所有修改都可以被语句之后(after)触发的触发器看到。

  • 导致触发器触发的数据改变(插入,更新,或者删除)通常是不能被一个before触发器里面执行的 SQL 命令看到的, 因为它还没有发生。

  • 不过,在 before 触发器里执行的 SQL 命令将会看到在同一个外层命令前面处理的行做的数据改变。 这一点需要我们仔细,因为这些改变时间的顺序通常是不可预期的; 一个影响多行的 SQL 命令可能以任意顺序访问这些行。

  • 在一个 after 触发器被触发的时候,所有外层命令产生的数据改变都已经完成, 可以被所执行的 SQL 命令看到。

 

有关数据可视性规则的更多信息可以在 Section 39.4 找到。 Section 32.4 里的例子包含这些规则的演示。

 

最后

以上就是舒适音响为你收集整理的触发器的全部内容,希望文章能够帮你解决触发器所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(57)

评论列表共有 0 条评论

立即
投稿
返回
顶部