一、前言
正则作为一种常用的字符串处理方式，在各种开发语言，甚至数据库中，都有自带的正则函数。但是正则函数有很多标准，不同标准对正则表达式的解析方式不一样，本次在迁移一个ORACLE数据库到openGauss时发现了一个关于 {}的差异点。
二、{}是做什么用的
在绝大部分的正则表达式规则中 {}表示对前面字符的重复次数，支持的形式为 {m}、{m,}、{,n}、{m,n}，其中m和n均为自然数，例如
| 表达式 | 说明 |
|---|---|
b{1} | 匹配1次b |
b{2,} | 匹配2次到无穷次b |
b{,3} | 匹配0次到3次b |
b{2,3} | 匹配2次到3次b |
三、{}的使用歧义
以下三条SQL均可以在ORACLE中执行
--匹配一个 $符号,此时 {}里的1表示 $的出现次数
select regexp_substr('aaaa${1}bbb','(\${1})') from dual;
--匹配${0个或任意个数的1}，此时{}以及{}内的字符按照字符串识别
select regexp_substr('aaaa${1}bbb','(\${1*})') from dual;
--匹配 ${一个空格加上0个或任意个数的1} ，此时{}以及{}内的字符按照字符串识别
select regexp_substr('aaaa${ }bbb','(\${ 1*})') from dual;
这里的规则在ORACLE中大概可以这么描述：
{}内如果不满足 {m}、{m,}、{,n}、{m,n}这四者之一的格式，则 {}不作为次数的声明符号，而是作为常规字符串进行识别。
但是上面第二个表达式在openGaussDB中会报错，因为这里还有一个规则：
如果 {}内的第一个字符是数字，则开始进入次数的解析逻辑，若解析不符合次数的规则，就报错。
查看openGauss源码，发现这段逻辑来自1998年的PG源码，数十年来未曾变过。
这里注意，此处并非BUG，只是正则标准不一致，我使用了7种开发语言来验证，发现JAVA和RUST中也同样是报错的，而PHP/JS/PYTHON/.NET/GO 中都不报错。
可以使用以下链接测试该正则表达式在不同开发语言中的表现
https://regex101.com/r/APc3is/1
四、相关源码
使用openGauss分析这个逻辑的时候，我断了几个点，找了几段源码
6 breakpoint keep y 0x0000000000fc4cd7 in parseqatom(vars*, int, int, state*, state*, subre*) at regcomp.cpp:915
breakpoint already hit 2 times
7 breakpoint keep y 0x0000000000fc42c4 in parsebranch(vars*, int, int, state*, state*, int) at regcomp.cpp:719
breakpoint already hit 2 times
8 breakpoint keep y 0x0000000000fc5040 in parseqatom(vars*, int, int, state*, state*, subre*) at regcomp.cpp:965
9 breakpoint keep y 0x0000000000fc510c in parseqatom(vars*, int, int, state*, state*, subre*) at regcomp.cpp:984
regc_lex.cpp, line 412.
regcomp.cpp, line 966.
当第一个字符是数字，而第二个不是期望的字符（0-9以及",“和”}"），就走到default报错
case '{':
NEXT();
m = scannum(v); //扫描数字
static int scannum(struct vars* v)
{
int n = 0;
while (SEE(DIGIT) && n < DUPMAX) {
n = n * 10 + v->nextvalue;
NEXT();
}
if (SEE(DIGIT) || n > DUPMAX) {
ERR(REG_BADBR);
return 0;
}
return n;
}
case L_EBND:
switch (c) {
case CHR('0'):
case CHR('1'):
case CHR('2'):
case CHR('3'):
case CHR('4'):
case CHR('5'):
case CHR('6'):
case CHR('7'):
case CHR('8'):
case CHR('9'):
RETV(DIGIT, (chr)DIGITVAL(c)); // {1*} 会在处理1的时候走到这里
break;
case CHR(','):
RET(',');
break;
case CHR('}'): /* ERE bound ends with } */
if (INCON(L_EBND)) {
INTOCON(L_ERE);
if ((v->cflags & REG_ADVF) && NEXT1('?')) {
v->now++;
NOTE(REG_UNONPOSIX);
RETV('}', 0);
}
RETV('}', 1);
} else
FAILW(REG_BADBR);
break;
case CHR('\\'): /* BRE bound ends with \} */
if (INCON(L_BBND) && NEXT1('}')) {
v->now++;
INTOCON(L_BRE);
RET('}');
} else
FAILW(REG_BADBR);
break;
default:
FAILW(REG_BADBR); // {1*} 会在处理*的时候走到这里
break;
}
有兴趣的可以自己下载源码去调试分析一下，这里我就不详细解读源码了。
五、其他国产数据库对{}的处理
DM8和YASHAN和ORACLE保持一致，能在 {}内不为次数时正确当成字符串；而其他几款基于PG、OG的数据库以及纯自研的OCEANBASE在这种情况下都会报错（mysql系不报错，但执行返回空）。
- DM 8
SQL> select regexp_substr('aaaa${1}bbb','(\${1*})') ;
LINEID REGEXP_SUBSTR('aaaa${1}bbb','(\${1*})')
---------- ---------------------------------------
1 ${1}
- YASHAN 23
SQL> select regexp_substr('aaaa${1}bbb','(\${1*})') from dual;
REGEXP_SUBSTR('AAAA$
--------------------
${1}
- KINGBASE 9
kingbase=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
kingbase-# /
ERROR: invalid regular expression: invalid repetition count(s)
- HIGHGO 6
highgo=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
ERROR: invalid regular expression: invalid
- GAUSSDB 503
gaussdb=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
ERROR: invalid regular expression: invalid repetition count(s)
CONTEXT: referenced column: regexp_substr
- OPENGAUSS 6.0
openGauss=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
ERROR: invalid regular expression: invalid repetition count(s)
CONTEXT: referenced column: regexp_substr
- GBASE 8c
postgres=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
ERROR: invalid regular expression: invalid repetition count(s)
CONTEXT: referenced column: regexp_substr
- VASTBASE v2.2 build 16
postgres=# select regexp_substr('aaaa${1}bbb','(\${1*})') ;
ERROR: invalid regular expression: invalid repetition count(s)
CONTEXT: referenced column: regexp_substr
- OCEANBASE 4.3
执行以下 SQL 失败
select regexp_substr('aaaa${1}bbb','(\${1*})') from dual
失败原因：
ErrorCode = 600, SQLState = 42000, Details = OBE-00600: internal error code, arguments: -5115, Got error 'U_REGEX_BAD_INTERVAL' from regexp
六、回到业务应用
其实本文中这种歧义用法，虽然在ORACLE中不报错，但是正确的编码方式应该是，对于想要识别成字符的保留符号，需要加上\进行转义，即(\$\{1*\})。
但结合实际业务规则来看，加转义的方式虽然看上去结果是对的，但逻辑其实是错的。
该段业务程序是在做模板字符串处理，系统中配置了多个字符串模板，模板中使用${1} ${2}这样的标记作为填充值的占位符。如果使用占位符使用到了 ${11} ，则(\$\{1*\})也能匹配上，导致结果错误。所以准确的做法应该为(\$\{1\}),即不应该有这个*，此时想替换第几个参数均能正确匹配。而为什么之前的业务代码中会有这个*，我猜想大概是当时的开发人员写的(\${1})匹配不到想要的数据时，发现加一个*就能匹配上，就这么用下去了，而该套系统多年以来，从未有超过9个参数的模板，因此该BUG一直未被人发现，直到进行本次国产化改造才挖出来。
七、总结
有很多所谓的"标准功能"，在不同的环境下有不同的"标准"，这些"标准"各有各的准则，经过多年的发展，很难强求其一致性。就连正则表达式这样常用的功能都有不同的标准，就不要指望ANSI SQL能让任意相同语句在每个数据库中执行结果完全一致了。在去O的过程中，经常能发现以往很多写得不标准的应用代码，此时正是好机会将这些代码变得更加规范。
- 本文作者： DarkAthena
- 本文链接： https://www.darkathena.top/archives/regexp-diff-with-repetition-count-between-opengauss-and-oracle
- 版权声明： 本博客所有文章除特别声明外，均采用CC BY-NC-SA 3.0 许可协议。转载请注明出处
