PostgreSQL 的正则表达式是使用 Henry Spencer 写的一个包来实现的。下面的正则表达式的大部分描述都是从他的手册页中逐字拷贝过来的。

正则表达式（RE），在 POSIX 1003.2 中定义，它有两种形式：扩展的 RE 或者是 ERE（大概地说就是那些在 egrep 里的），基本的 RE 或者是 BRE（大概地说就是那些在 ed 里的）。PostgreSQL 支持两种形式，并且还实现了一些 POSIX 标准中没有但是在类似 Perl 或者 Tcl 这样的语言中得到广泛应用的一些扩展。使用了那些非 POSIX 扩展的 RE 叫高级 RE，或者本文档里说的 ARE。ARE 几乎完全是 ERE 的超集，但是 BRE 有几个符号上的不兼容（以及更多的限制）。我们首先描述 ARE 和 ERE 形式，描述那些只适用于 ARE 的特性，然后描述 BRE 的区别是什么。

一个正则表达式被定义为一个或更多分支，它们之间被|分隔。只要能匹配其中一个分支的东西都能匹配正则表达式。

一个分支是零个或多个量化原子或约束，连接在一起。它匹配第一个的匹配项，然后是第二个的匹配项，依此类推；一个空分支匹配空字符串。

一个量化原子是一个原子，后面可以跟一个量词。没有量词时，匹配一次原子所匹配的内容；有量词时，按量词指定的次数匹配原子所匹配的内容。原子可以是表 9.17 列出的任何一种形式。可用量词及其含义见表 9.18。

一个约束匹配一个空串，但只是在满足特定条件下才匹配。约束可以在能够使用原子的地方使用，只是它不能跟着量词。简单的约束在表 9.19 里显示；更多的约束稍后描述。

RE 不能以反斜线（\）结尾。

使用{...}的形式被称作范围。一个范围内的数字 m 和 n 都是无符号十进制整数，允许的数值从 0 到 255（包含）。

非贪婪量词（仅适用于 ARE）与对应的普通（贪婪）量词匹配相同的可能内容，但优先选择最少的匹配次数，而不是最多的匹配次数。详见第 9.7.3.5 节。

先行和后行约束不能包含反向引用（参见第 9.7.3.3 节），其中的所有圆括号都视为非捕获圆括号。

方括号表达式是用[] 括起来的字符列表。通常，它匹配列表中的任意单个字符（但请参见下文）。如果列表以^开头，则匹配任意不在列表剩余部分中的单个字符。如果列表中的两个字符用-分隔，则表示排序序列中这两个字符之间的完整字符范围（包含两个端点）；例如，ASCII 中的[0-9] 匹配任意十进制数字。两个范围共享一个端点是不合法的，例如 a-c-e。范围高度依赖排序序列，因此可移植程序应避免依赖它们。

想在列表中包含字面字符]，可以让它做列表的首字符（如果使用了^，需要放在其后）。想在列表中包含字面字符-，可以让它做列表的首字符或者尾字符，或者一个范围的第二个端点。想在列表中把字面字符-当做范围的起点，把它用[.和.] 包围起来，这样它就成为一个排序元素（见下文）。除了这些字符本身、一些用[的组合（见下段）以及转义（只在 ARE 中有效）以外，所有其它特殊字符在方括号表达式里都失去它们的特殊含义。特别是，在 ERE 和 BRE 规则下\ 不是特殊的，但在 ARE 里，它是特殊的（引入一个转义）。

在一个方括号表达式里，一个排序元素（一个字符、一个被当做一个单一字符排序的多字符序列或者一个表示上面两种情况的排序序列名称）包含在[.和.] 里面的时候表示该排序元素的字符序列。该序列被当做该方括号列表的一个单一元素。这允许一个包含多字符排序元素的方括号表达式去匹配多于一个字符，例如，如果排序序列包含一个 ch 排序元素，那么 RE [[.ch.]]*c 匹配 chchcc 的头五个字符。

在方括号表达式里，包围在[=和=] 里的排序元素是一个等价类，代表等效于那一个的所有排序元素的字符序列，包括它本身（如果没有其它等效排序元素，那么就好像封装定界符是[.和 .]）。例如，如果 o 和^是一个等价类的成员，那么[[=o=]]、[[=^=]] 和[o^] 都是同义的。一个等价类不能是一个范围的端点。

在方括号表达式中，用[:和:] 括起来的字符类名称表示属于该类的所有字符。字符类不能作为范围的端点。POSIX 标准定义了以下字符类名称：alnum（字母和数字）、alpha（字母）、blank（空格和制表符）、cntrl（控制字符）、digit（数字）、graph（空格以外的可打印字符）、lower（小写字母）、print（包括空格的可打印字符）、punct（标点符号）、space（任意空白字符）、upper（大写字母）和 xdigit（十六进制数字）。对于 7 位 ASCII 字符集中的字符，这些标准字符类在各平台上的行为通常一致。给定的非 ASCII 字符是否属于其中某个类，取决于正则表达式函数或操作符使用的排序规则（参见第 23.2 节），默认则取决于数据库的 LC_CTYPE 区域设置（参见第 23.1 节）。即使区域设置名称相似，非 ASCII 字符的分类也可能因平台而异。（但 C 区域设置不会将任何非 ASCII 字符归入这些类。）除了这些标准字符类，PostgreSQL 还定义了恰好包含 7 位 ASCII 字符集的 ascii 字符类。

方括号表达式里有两个特例：方括号表达式[[:<:]] 和[[:>:]] 是约束，分别匹配一个单词开头和结束的空串。单词定义为一个单词字符序列，前面和后面都没有其它单词字符。单词字符是 alnum 字符（按上面介绍的 POSIX 字符类定义）或下划线。这是一个扩展，兼容 POSIX 1003.2，但那里面并没有说明，而且在准备移植到其他系统里去的软件里一定要小心使用。通常下文描述的约束转义更好些（它们并非更标准，但是更容易键入）。

转义是以\ 开头，后面跟着一个字母或数字字符的特殊序列。转义有好几种变体：字符输入转义、字符类简写转义、约束转义以及反向引用。在 ARE 里，如果一个\ 后面跟着一个字母或数字，但是并未组成一个合法的转义，那么它是非法的。在 ERE 中没有转义：在方括号表达式之外，一个后面跟着字母或数字字符的\ 只是表示该字符是一个普通的字符，而且在一个方括号表达式里，\ 是一个普通的字符（后者是 ERE 与 ARE 之间唯一的实际不兼容之处）。

字符输入转义便于在 RE 中指定不可打印或其他不便输入的字符，见表 9.20。

字符类简写转义用来提供一些常用的字符类简写。它们显示在表 9.21 中。

约束转义是以转义形式书写的约束，在满足特定条件时匹配空字符串，见表 9.22。

反向引用（\n）匹配数字 n 指定的被前面的圆括号子表达式匹配的同一个串（参阅表 9.23）。例如，([bc])\1 匹配 bb 或者 cc，但是不匹配 bc 或者 cb。RE 中子表达式必须完全在反向引用前面。子表达式以它们的左圆括号的顺序编号。非捕获圆括号并不定义子表达式。

十六进制位是 0-9、a-f 和 A-F。八进制位是 0-7。

指定 ASCII 范围（0–127）之外的值的数字字符输入转义的含义取决于数据库编码。当编码是 UTF-8 时，转义值等价于 Unicode 代码点，例如 \u1234 表示字符 U+1234。对于其他多字节编码，字符输入转义通常只是指定该字符的字节值的串接。如果该转义值不对应数据库编码中的任何合法字符，将不会发生错误，但是它不会匹配任何数据。

字符输入转义总是被当作普通字符。例如，\135 是 ASCII 中的]，但\135 并不终止一个方括号表达式。

在方括号表达式中，\d、\s 和 \w 会失去其外层方括号，而 \D、\S 和 \W 则是非法的。（因此，例如 [a-c\d] 等同于 [a-c[:digit:]]。此外，等同于 [a-c^[:digit:]] 的 [a-c\D] 是非法的。）

单词的定义与上文[[:<:]] 和[[:>:]] 的说明相同。方括号表达式中不允许使用约束转义。

除了上面描述的主要语法之外，还有几种特殊形式和杂项语法。

RE 可以以两种特殊的引导前缀之一开头。如果 RE 以***:开头，余下部分就被视为 ARE。（这在 PostgreSQL 中通常没有影响，因为 RE 默认被视为 ARE；但如果通过正则表达式函数的 flags 参数指定了 ERE 或 BRE 模式，它就会产生影响。）如果 RE 以***=开头，余下部分就作为按字面解释的字符串处理，所有字符都视为普通字符。

一个 ARE 可以以嵌入选项开头：一个序列(?xyz)（这里的 xyz 是一个或多个字母字符）声明影响剩余 RE 的选项。这些选项覆盖任何先前确定的选项 — 特别地，它们可以覆盖一个正则表达式操作符隐含的大小写敏感的行为，或者覆盖正则表达式函数的 flags 参数所指定的选项。可用的选项字母在表 9.24 中显示。注意这些同样的选项字母也被用在正则表达式函数的 flags 参数中。

嵌入选项从结束该序列的) 处开始生效。它们只能出现在 ARE 的开头（如果存在***:引导前缀，则位于该前缀之后）。

除了通常的紧凑 RE 语法（其中所有字符都有意义）之外，还有一种扩展语法，可以通过指定嵌入的 x 选项来使用。在扩展语法中，RE 中的空白字符会被忽略，同样被忽略的还有#与其后的换行符（或 RE 末尾）之间的所有字符。这使得复杂的 RE 可以分段并添加注释。此基本规则有三个例外：

在这里，空白字符包括空格、制表符、换行符，以及属于 space 字符类的任何字符。

最后，在 ARE 里，方括号表达式外面，序列(?#ttt)（其中 ttt 是任意不包含一个) 的文本）是一个注释，它被完全忽略。同样，这样的东西是不允许出现在多字符符号的字符中间的，例如 (?:。这种注释更像是一种历史产物而不是一种有用的设施，并且它们的使用已经被废弃；请使用扩展语法来替代。

如果指定了开头的***=引导前缀，那么这些元语法扩展都不能使用，因为这表示把用户输入作为按字面解释的字符串，而非 RE 处理。

在 RE 可以在给定串中匹配多于一个子串的情况下，RE 匹配串中最靠前的那个子串。如果 RE 可以匹配在那个位置开始的多个子串，要么是取最长的子串，要么是最短的，具体哪种，取决于 RE 是贪婪的还是非贪婪的。

一个 RE 是否贪婪取决于下面规则：

上面的规则所描述的贪婪属性不仅仅适用于独立的量化原子，而且也适用于包含量化原子的分支和整个 RE。这里的意思是，匹配是按照分支或者整个 RE 作为一个整体匹配最长或者最短的可能子串。一旦整个匹配的长度确定，那么匹配任意特定子表达式的部分就基于该子表达式的贪婪属性进行判断，在 RE 里面靠前的子表达式的优先级高于靠后的子表达式。

一个相应的示例：

SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
结果：123
SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
结果：1

在第一个示例里，RE 作为整体是贪婪的，因为 Y* 是贪婪的。它可以匹配从 Y 开始的东西，并且它匹配从这个位置开始的最长的串，也就是，Y123。输出是这里的圆括号包围的部分，或者说是 123。在第二个示例里，RE 总体上是一个非贪婪的 RE，因为 Y*?是非贪婪的。它可以匹配从 Y 开始的最短的子串，也就是说 Y1。子表达式[0-9]{1,3}是贪婪的，但是它不能修改总体匹配长度的决定；因此它被迫只匹配 1。

简而言之，如果一个 RE 同时包含贪婪和非贪婪的子表达式，那么总的匹配长度要么是尽可能长，要么是尽可能短，这取决于给整个 RE 赋予的属性。给子表达式赋予的属性只影响在这个匹配里，各个子表达式相对于其他子表达式能“吃掉”多少内容。

量词{1,1}和{1,1}?可以分别用于在一个子表达式或者整个 RE 上强制贪婪或者非贪婪。当需要整个 RE 具有不同于从其元素中推导出的贪婪属性时，这很有用。例如，假设我们尝试将一个包含一些数字的字符串分隔成数字以及在它们之前和之后的部分，我们可能会尝试这样做：

SELECT regexp_match('abc01234xyz', '(.*)(\d+)(.*)');
结果：{abc0123,4,xyz}

这不会有用：第一个.* 是贪婪的，因此它会“吃掉”尽可能多的字符而留下\d+去匹配在最后一个可能位置上的最后一个数字。我们可能会通过让它变成非贪婪来修复：

SELECT regexp_match('abc01234xyz', '(.*?)(\d+)(.*)');
结果：{abc,0,""}

这也不会有用：因为现在 RE 作为整体来说是非贪婪的，因此它会尽快结束全部的匹配。我们可以通过强制 RE 整体是贪婪的来得到我们想要的：

SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
结果：{abc,01234,xyz}

将 RE 的整体贪婪性与各组件自身的贪婪性分开控制，为处理变长模式提供了很大的灵活性。

在决定更长或者更短的匹配时，匹配长度是以字符衡量的，而不是排序元素。一个空串会被认为比什么都不匹配长。例如：bb* 匹配 abbbc 的中间三个字符；(week|wee)(night|knights) 匹配 weeknights 的所有十个字符；而(.*).* 匹配 abc 的时候，圆括号包围的子表达式匹配所有三个字符；当(a*)* 被拿来匹配 bc 时，整个 RE 和圆括号子表达式都匹配一个空串。

如果指定不区分大小写的匹配，其效果近似于字母表中的所有大小写差别都消失了。当存在大小写形式的字母作为普通字符出现在方括号表达式之外时，实际上会转换为包含其大小写形式的方括号表达式，例如 x 变成[xX]。当它出现在方括号表达式内部时，其所有大小写形式都会加入该表达式，例如[x] 变成[xX]，[^x] 变成[^xX]。

如果指定了换行敏感的匹配，.和使用^的方括号表达式将永远不会匹配换行字符（这样，匹配就不会跨越行，除非 RE 显式安排了跨行匹配）并且^和$除了分别匹配串开头和结尾之外，还将分别匹配换行后面和前面的空串。但是 ARE 转义\A 和\Z 仍然只匹配串的开头和结尾。

如果指定了部分换行敏感的匹配，那么它影响.和方括号表达式，这个时候和换行敏感的匹配一样，但是不影响^和$。

如果指定了逆部分换行敏感匹配，那么它影响^和$，其作用和在换行敏感的匹配里一样，但是不影响.和方括号表达式。这个并不是很有用，只是为了满足对称性而提供的。

在这个实现里，对 RE 的长度没有特别的限制。但是，那些希望高移植性的程序应该避免使用长度超过 256 字节的 RE，因为 POSIX 兼容的实现可以拒绝接受这样的 RE。

ARE 与 POSIX ERE 实际不兼容的唯一特性是：\ 在方括号表达式中不会失去特殊含义。其他所有 ARE 特性所使用的语法，在 POSIX ERE 中都是非法的，或其效果未定义或未指定；引导前缀的*** 语法同样不属于 POSIX 的 BRE 或 ERE 语法。

许多 ARE 扩展借鉴自 Perl，但其中一些经过了整理和修改，也未实现少数 Perl 扩展。需要注意的不兼容之处包括\b、\B、不对末尾换行符作特殊处理、取反的方括号表达式也受换行敏感匹配影响、先行和后行约束中对圆括号及反向引用的限制，以及采用最长或最短匹配而非首次匹配的语义。

ARE 与旧版 ERE 语法存在两点重要的不兼容，这里比较的是 7.4 之前的 PostgreSQL：

BRE 在几个方面和 ERE 不太一样。在 BRE 中，|、+和?都是普通字符并且没有与它们功能等价的东西。范围的定界符是\{和\}，而{和}本身是普通字符。嵌套的子表达式的圆括号是\(和\)，而(和) 自身是普通字符。除非在 RE 开头或者是圆括号子表达式开头，^都是一个普通字符。除非在 RE 结尾或者是圆括号子表达式的结尾，$是一个普通字符。如果* 出现在 RE 开头或者是圆括号封装的子表达式开头（前面可能有^），那么它是个普通字符。最后，可以用单数字的反向引用，\<和\> 分别是[[:<:]] 和[[:>:]] 的同义词；在 BRE 中没有其它可用的转义。

自 SQL:2008 起，SQL 标准包含一个按 XQuery 正则表达式标准执行模式匹配的 LIKE_REGEX 操作符。PostgreSQL 尚未实现此操作符，但使用 regexp_match() 函数可以得到非常相似的行为，因为 XQuery 正则表达式与前述 ARE 语法十分接近。

现有基于 POSIX 的正则表达式功能与 XQuery 正则表达式之间的显著区别包括：