REGEXP_MATCHES返回text[]数组，每行匹配生成一个数组，含全部捕获组（无则为完整匹配），索引从1开始；默认仅首匹配，加'g'标志才全局匹配；不可直接布尔比较，需配合LATERAL或~操作符使用。
REGEXP_MATCHES 函数的基本用法和返回值结构
REGEXP_MATCHES 不是返回布尔值，而是返回一个 text[]（文本数组）结果集，每行匹配对应一个数组——哪怕只捕获一个子组，也会包在数组里。它默认**贪婪匹配全部字符串**，且**只返回第一个匹配项**（除非加 'g' 标志）。如果你习惯 JavaScript 的 match() 或 Python 的 re.findall()，这里容易误以为它会自动展开所有匹配。
基本调用形式：REGEXP_MATCHES(string, pattern, flags)。其中 flags 是可选字符串，常见值有 'g'（全局）、'i'（忽略大小写）、'm'（多行模式）等，可组合如 'gi'。
示例：提取邮箱本地部分（@之前）：
SELECT REGEXP_MATCHES('contact@example.com', '([a-zA-Z0-9._%+-]+)@', 'g');
返回：{contact}（注意是单元素数组）。
为什么直接 SELECT REGEXP_MATCHES 有时“没结果”或报错
常见错误是把 REGEXP_MATCHES 当作标量函数用，比如写成 SELECT name FROM users WHERE REGEXP_MATCHES(name, '^[A-Z]') = true ——这会失败，因为返回的是数组，不是布尔值，也不能直接和 true 比较。
正确做法分场景：
- 判断是否匹配：改用
~操作符，例如name ~ '^[A-Z]' - 需要提取内容：保留
REGEXP_MATCHES，但要用FROM子句或LATERAL联查，例如：SELECT u.name, m[1] AS first_part FROM users u, LATERAL REGEXP_MATCHES(u.email, '([^@]+)@') m;
- 想一行一匹配：必须加
'g'标志，否则只返回首个匹配；不加则对无匹配的行返回空结果集（即该行被过滤掉）
捕获组数量与数组下标的关系
REGEXP_MATCHES 返回的数组长度等于正则中**左括号的数量**（即捕获组数），未匹配的捕获组位置为 NULL，不是空字符串。这点和大多数语言不同——比如 REGEXP_MATCHES('abc', '(a)|(b)') 对 'abc' 返回 {a,NULL}，而不是跳过第二个组。
关键细节：
- 索引从 1 开始：
m[1]是第一个捕获组，m[2]是第二个 - 非捕获组（
(?:...)）不计入数组长度 - 如果正则无括号，返回单元素数组，内容是整个匹配字符串，即
m[1]等价于完整匹配 - 使用
'g'时，每行输出对应一次匹配，每个匹配生成独立数组
性能和兼容性注意事项
REGEXP_MATCHES 在 PostgreSQL 10+ 中稳定可用，但底层依赖的是 POSIX ERE（扩展正则），**不支持 \d、\s、\b 等 Perl 风格简写**——必须写成 [0-9]、[[:space:]]、[[:<:>（词首）等。写错会静默失败或行为异常。</:>
性能方面：
- 带
'g'标志比不带慢不少，尤其在长文本上；若只需判断存在性，坚持用~或~* - 避免在 WHERE 中对大字段反复调用
REGEXP_MATCHES；考虑提前用生成列或物化视图预计算 - 正则本身尽量锚定（如加
^或$），减少回溯开销
真正麻烦的是跨版本迁移：PostgreSQL 9.x 的 regexp_matches()（小写）行为略有差异，且旧版不支持 LATERAL 直接展开，容易卡在语法层面。
