preg_match() return the longest match - php

Question

Disclaimer: Unless I'm not seeing, this is not the same as described in this topic and I'll need some time to fully explain the situation.
A very long time ago I asked a question about how to use the REGEXP operator in a SQLite statement. The operator is not implemented by default but it can be in runtime.
Well.. As you can see by the dates, that worked for me for years. Not entirely with the help of that topic (someone in SQLite mailing list showed me a trick) but it worked well.
Because preg_match() works differently of ereg() (as I've heard), by returning positively immediately after the first match, I took an additional precaution before populate that SQLite database by sorting the REGEXES (I'm sure this is not the right plural form) from the longest (more specific) to the shortest (more generic).
Not a big deal, just a simple uasort() using strlen().
Considering a fictional movie management catalog with two URLs like management/actors and management/actors/add, this sorting trick saved me from having false-positives while accessing the first URL and have SQLite responding with the second resultset only because both of them have the same immutable part management/actors
This is the current implementation:
$this -> dbh
-> sqliteCreateFunction(
'REGEXP',
function( $r, $s ) {
return ( preg_match( sprintf( '#^%s$#i', $r ), $s ) != 0 );
},
2
);
Being $this -> dbh the class property with the PDO instance used.
The situation now is different because this sorting trick did not consider one possibility: Two routes where the most generic is also the longest route. For example: management/actors/add and management/actors/overview.
Conceptually, the second route is more generic because it refers to a simple dashboard listing all the actors and should go to the bottom. In fact it's just an alias for management/actors.
And the second route is more specific because it routes the form responsible to add a new record and thus should go to the top
These routes are analyzed from PHP doc comments spread around Controller classes like this:
/**
* Overview
*
* !Route GET, management/actors
* !Route GET, management/actors/overview
*/
final public function overview() {}
/**
* Add
*
* !Route GET, management/actors/add
*/
final public function add() {}
And comes in this order:
management/actors
management/actors/overview
management/actors/add
Because I need to identify the Action method they're structurd in different array indexes with the class method name as key:
Array(
'overview' => array(
[0] => management/actors
[1] => management/actors/overview
),
'add' => array(
[0] => 'management/actors/add'
)
)
Like I said the sorting works and can make this structure become:
Array(
'overview' => array(
[0] => management/actors/overview
[1] => management/actors
),
'add' => array(
[0] => 'management/actors/add'
)
)
But the whole component fails to work because of preg_match() implementation of SQLite REGEX operator.
So far, the only way, I managed to workaround this issue was to develop the Controller classes like this:
/**
* Add
*
* !Route GET, management/projects/add
*/
final public function add() {}
/**
* Overview
*
* !Route GET, management/projects
* !Route GET, management/projects/overview
*/
final public function overview() {}
I mean, in the reverse order.
Fine! All applications in a certain way have their own oddities and I could live with that but, perhaps, in the future, someone else may open this code and give it some maintenance and may not be aware of this limitation.
That said (finally) I wish to know if there is a way to increase preg_match()'s gluttony and make it not stop in the first positive occurrence and match the longest possible like ereg does, or at least I think it does, I've never saw it in action.
Or an alternative solution, of course :p
As requested in comments, some examples of the REGEXES, listed in the order they're inserted in the SQLite database (after sorting):
management/projects/overview\b(.*?)
management/projects/add\b(.*?)
management/projects\b(.*?)
They're very simple REGEXES. They match mainly the Request URI. In the end of the REGEX I have only a border to distinguish the fixed string text from the variable part that might exists (like Xdebug profiling GET argument)