Inconsistent escaping of regex parentheses

[Tim]

Hi all,

I'm in the process of upgrading an old 2.2.0 installation of
FreeRADIUS to a more sane 3.0.17 release (stock from current CentOS).

I've hit a problem while trying to migrate the MySQL module due to the
way that regular expressions seem to be getting escaped, and was
hoping someone could see if anything looks amiss.

We have a custom attribute, My-Regex-Pattern, that is defined as a
simple string.

In this instance, the attribute is held within the radgroupcheck MySQL
table with the following regex stored as a string:

        @(.+\\.)?(DOMAIN1|DOMAIN2)$


During the authorize_check_query stage, a stored procedure is
successfully called and the attribute is returned along with the
correct value:

(1) sql: Executing select query: Call getChecks('foo at bar.com');
(1) sql: User found in radcheck table
(1) sql: Conditional check items matched, merging assignment check items
(1) sql:   My-Regex-Pattern := "@(.+\\.)?(DOMAIN1|DOMAIN2)$"


However, when that string is later expanded via Unlang, the escaping
appears to break as the opening parentheses get escaped while the
closing ones do not:

(1)         if ( &control:My-Regex-Pattern && &User-Name =~
/%{control:My-Regex-Pattern}/i ) {
(1)         EXPAND %{control:My-Regex-Pattern}
(1)            --> @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$
(1) ERROR: @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$
(1) ERROR:           ^ Pattern compilation failed: unmatched parentheses
(1)         ERROR: Failed retrieving values required to evaluate condition


The error message makes perfect sense, but I'm unclear why this is
happening and whether it's a misconfiguration, a bug or simply new
intended behaviour that the migration needs to adapt to use.

'correct_escapes' is set to true and the sql modules 'safe_characters'
option has been left as its default value.


Thanks in advance.

--
Tim