myrocks requires use of new class in facebook mysql Regex_list_handler

5.6:
https://github.com/percona/percona-server/pull/1428

5.7:
https://github.com/percona/percona-server/pull/1429

Postponed, but not cancelled. What they have works for them currently in MyRocks, even if based on std::regex, which caused this entire discussion in the first place. If we propose a change, I have to also do the work to propose they change all of their options, everything that uses Regex_list_handler, options of which we have mostly removed. Then they would have to deal with the (correctly) changed format (removing the silly artificial delimiter and going to the 'traditional' format of my_regex and not the 'modern' of std::regex). The problem with this for them is it is already deployed in production.

They are thrilled to get contributions. Something like this that impacts their production deployments in a potentially adverse way would not be accepted. In other words, they are moving forward, my_regex is not forward. This is one place where I have absolutely no problem diverging until we reach a point where everything (including SQL layer) switches over to 'modern' regex and is all based on the same common behavior, documentation and library. IMHO this was a bad decision for them to base things on a highly incomplete/experimental implementation when a known good and thoroughly documented implementation already existed, and we will be correcting that.

Upstream has postponed their 4.9 migration (and it's coming from RocksDB not MyRocks), and IMHO they'd appreciate the patch to make our and MariaDB lives easier.

This will not be submitted upstream as there is no reason to. They are moving forward to 4.9 and not concerned with maintaining compatibility with older/unsupported c libs. We do not have that luxury. We have removed all but two of the uses of this facility anyway, but will likely be re-introducing one in the way of the read_free_tables option as we move RFR up into the SQL layer.

I think all regex across the server should conform to the same standard, so using std::regex for some options and my_regex (based on 'traditional' regex) for others introduces possible confusion. SQL regex is clearly documented and we can piggy back on that. In this case, I am not at all concerned with upstream Facebook MySQL comparison/compatibility because IMHO it was done wrong from the very start when considering that MySQL has an existing regex facility and upstream based on a documented incomplete/experimental implementation. In other words, I think this change, to embrace my_regex entirely where we want/need regex, is the right thing to do for us.

Comma to OR conversion could be convenient to some people - not that we should support it, unless there is overwhelming demand - but upstream is likely to keep it, resulting in extra work in submitting this upstream