compatibility and bandwidth saving.
Memory issues by caching should not arise, as the used cache will (in our
previously used cases) only cache index fields and max. 200 relation rows.
I tested performance on my machine: By fetching 400kb of data twice via
mysql_fetch_row() -> mysql_data_seek() -> mysql_fetch_row() this was
performed in 0.25 seconds. By fetching it once and caching in a PHP array
via mysql_fetch_row -> foreach this is performed in 0.32 seconds.
With usual data as used in PMA (10kb) I could only detect a performance
change of 0.009 seconds, which is respectable I think.
By not using mysql_data_seek we are later able to use global mysqli
USE_RESULT options to fetch rows singly. I discussed that yesterday with
Rabus, and if there are any objections we can surely discuss that further on
the list.
The lines
$re0 = '@(^|(\\\\\\\\)+|[^\\\\])'; // non-escaped wildcards
$re1 = '@(^|[^\])(\\\)+'; // escaped wildcards
as they currently where made no sense to me, because the single [^\] should be replaced to [^\\\\] as well, doesn't it? To not seriously break more stuff I decided to revert to the previous mechanism here.
I will do more serious tests the next days and will actually work with my PMA again and I pay close attention to see if there are any issues left.
I also searched through the code to see if the setting of the array points from former while() constructs was in any way used [current(), next(), prev(), key(), end(), each()] but did find none.