PostgreSQL regexp_replace 只替换了第一处匹配

用 regexp_replace(name, '[.]', '') 删除姓名缩写中的句点，A.B. Chen 却只变成 AB. Chen，第二个点还在。给 [.] 加一层捕获括号也没有改变结果，因为问题不在于能否匹配点，而在于函数默认只替换第一处匹配。

下面针对 PostgreSQL 的三参数形式，以及第四个参数为文本标志的形式。若现有调用还传入起始位置和匹配序号，需要先分清它使用的是另一组参数。

把替换次数与正则匹配分开核对

下面是只读 SQL 示例，可在测试会话中对照三个表达式：

SELECT
    regexp_replace('A.B. Chen', '[.]', '') AS first_only,
    regexp_replace('A.B. Chen', '([.])', '') AS captured_first,
    regexp_replace('A.B. Chen', '[.]', '', 'g') AS all_matches;

前两列预期都是 AB. Chen，第三列才是 AB Chen。括号建立捕获组，不会要求函数继续寻找下一处；g 放在第四个文本参数里，才表示替换全部匹配。

[.] 在这里匹配字面句点。不要为了修复次数问题改成裸 .，因为裸点是正则通配符，会改变匹配目标。也不要把 JavaScript 的 /pattern/g 写法直接塞进 SQL 字符串；PostgreSQL 的模式与标志是分开的参数。

若已有其他文本标志，需要保留它们。例如原来使用 i 忽略大小写，改成 gi 才能同时保留忽略大小写和全局替换；仅把 i 换成 g 会改变原来的匹配规则。

只删除固定字符时，可以不用正则

需求如果只是删除所有字面句点，replace 就能表达：

SELECT replace('A.B. Chen', '.', '') AS cleaned_name;

预期同样为 AB Chen。replace 替换所有与给定文本相等的片段，点在它的第二个参数中没有正则含义。

如果原需求是替换一类字符、按上下文匹配，或使用捕获组重排文本，则应继续使用相应正则，不能为了得到全局效果直接换成字面替换。函数名称相似，参数表达的规则并不相同。

带匹配序号的调用另有规则

支持 start、N 参数的 PostgreSQL 版本还提供另一种形式。N 大于 0 时只替换第 N 个匹配，N 为 0 时替换从指定起点开始的全部匹配；显式指定 N 后，g 标志被忽略。

因此，看到已有代码包含整数参数，不要只在末尾补一个 g 就认定修复完成。核对当前版本支持的函数签名，以及业务究竟要求第几处、从哪里开始。本文的简单修复使用第四参数为文本 'g' 的形式，不需要引入起始位置或序号。

先比对结果，再决定是否写回

实际处理已有字段时，可先在测试副本中同时返回原值和转换结果。以下 people、id、name 是表字段示例，需要按实际结构替换：

SELECT
    id,
    name AS original_name,
    regexp_replace(name, '[.]', '', 'g') AS candidate_name
FROM people
WHERE id IN (101, 102, 103)
ORDER BY id;

样例应包含没有点、一个点、连续多个点，以及业务上本应保留点的值。全局替换会处理模式匹配到的每一处，不会理解姓名、缩写或业务编码的含义；如果只有特定位置允许修改，应收紧模式或筛选范围。

查询不报错，只能说明表达式可执行，不能证明批量清洗范围正确。确认结果后再通过应用已有的变更流程写回，保留原始值或可恢复备份。删除字符通常无法靠反向替换还原，不能把“再补几个点”作为回退方法。只调整读取表达式的场景则保留旧查询版本即可。