if the first character in {} is a number, the parsing logic of the number will begin. If the parsing does not meet the number rule, an error will be reported.
Looking at the openGauss source code, I found that this logic comes from the PG source code in 1998 and has not changed for decades.
Please note that this is not a bug, but the regular expression standard is inconsistent. I used 7 development languages to verify and found that JAVA and RUST also report errors, but PHP/JS/PYTHON/.NET/GO does not report errors.
If you are interested, you can download the source code to debug and analyze it yourself. I will not interpret the source code in detail here.
5. How other domestic databases handle {}
DM8, YASHAN and ORACLE are consistent and can correctly kuwait phone number data treat {} as a string when it is not a number. However, several other databases based on PG and OG and the purely self-developed OCEANBASE will report an error in this case (MySQL will not report an error, but the execution returns nothing).
ErrorCode = 600, SQLState = 42000, Details = OBE-00600: internal error code, arguments: -5115, Got error 'U_REGEX_BAD_INTERVAL' from regexp
6. Back to business applications
In fact, although this ambiguous usage in this article does not report an error in ORACLE, the correct encoding method should be to escape the reserved symbols that you want to recognize as characters, that is, (${1*}).
However, combined with actual business rules, although the escape method seems to be correct, the logic is actually wrong.
This business program is doing template string processing. Multiple string templates are configured in the system. Tags such as ${1} ${2} are used as placeholders for fill values in the template. If the placeholder is ${11}, (${1*}) can also match, resulting in an incorrect result. So the correct approach should be (${1}), that is, there should not be this *. At this time, any parameter you want to replace can be matched correctly. As for why there was this * in the previous business code, I guess it was probably because when the (${1}) written by the developer at the time could not match the desired data, he found that adding a * could match it, so he continued to use it. For many years, this system has never had a template with more than 9 parameters, so the BUG has not been discovered until this localization transformation was carried out.