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.
This is a hook-in to the 'delete multiple records' and basically just wraps all data in some kind of Ueber-Array. It should be compatible with single records editing. I tried various combinations already and it seems to work. But this can heavily break stuff, so expect this to be EXPERIMENTAL! We should only release RC1 after this has been thoroughly tested (will do so in the next days by myself).
What maybe needs fixing is the way of evaluating $goto/ $err_url and similars. As I am not much into that redirection stuff, maybe one can see if I did something wrong in the area.
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.