Yes but then you can't run mysql_fetch_array() on a regular array, only a result set array. This means you have to re-engineer mysql_fetch_array() or actually define the indexes: $array[1], $array[2] rather than $data['name'], $data['price'], etc.
No, you can still use $data['name'], $data['price'], etc. mysql_fetch_array() returns an array with duplicate indices (both numeric and associative). If you provide MYSQL_ASSOC as the second argument, or use mysql_fetch_assoc() as in my example, it will return an array with associative indices only.
There are several ways to get around this, all of them either overly complicated (combine statements in one loop, store in regular array) or DB intensive (multiple queries).
Combining the statements into one loop is more efficient since it reduces two or three passes over the result set into one pass. Storing the result set in an array of arrays is not complicated, as I demonstrate below. mysql_data_seek() does not involve multiple queries, but a movement of the internal result set pointer.
It seems like it's so obvious that this is a very necessary feature how could PHP not contain such functionality?
What exactly is the functionality that you are looking for?
EDIT:
Here is a concrete example of using mysql_data_seek:
$query = "select * from products";
$result = mysql_query($query);
while ($product = mysql_fetch_assoc($result)) {
echo $product['name'] . ': $' . $product['price'] . "<br />\n";
}
mysql_data_seek($result, 0);
while ($product = mysql_fetch_assoc($result)) {
echo $product['name'] . ' costs $' . $product['price'] . "<br />\n";
}
Here is a concrete example of copying the result set into an array:
$query = "select * from products";
$result = mysql_query($query);
$products = array();
while ($product = mysql_fetch_assoc($result)) {
$products[] = $product;
}
foreach ($products as $product) {
echo $product['name'] . ': $' . $product['price'] . "<br />\n";
}
foreach ($products as $product) {
echo $product['name'] . ' costs $' . $product['price'] . "<br />\n";
}
How are they any more complicated or DB intensive than what you have in mind?