dev/core#2793 - Add REGEXP/NOT REGEXP SQL operators

[pfigel]

Overview

This adds the REGEXP and NOT REGEXP operators to API4 and SearchKit.

Before

REGEXP/NOT REGEXP were not usable as operators in API4 or SearchKit.

After

REGEXP/NOT REGEXP can be used as operators in API4 and SearchKit.

Technical Details

Some questions re: case-sensitivity in https://lab.civicrm.org/dev/core/-/issues/2793; solved via #21301

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

@pfigel this looks great. One question though: if case-sensitivity has been solved in the SQL functions front, should we remove the /i from the php-based search?

[pfigel]

@colemanw Good question. If we include /i, the default behaviour of REGEXP in PHP-based queries matches the default behaviour of REGEXP in MySQL. At the same time, this prevents us from doing any case-sensitive matching in PHP-based queries, which can be achieved via BINARY() in MySQL.

I'd say: Include /i if we want to prioritize compatibility, or remove it if we want to go with principle of least surprise (my assumption being that most developers would expect regular expressions to be case-sensitive by default).

[colemanw]

I say remove it. You can always build insensitivity into your regex if you need it (e.g. /[a-zA-Z]/) but you can't take it out if we force it to be there.

[pfigel]

That makes sense - should be good now.

[colemanw]

Just noting that this does affect SearchKit. I presume that users who don't know what "Matches Regexp" means will stay away from it.