Fix for bug #49357 (MySQLi extension fails to recognize POINT (spatial) colums).

Do yourself a favour and use mysqlnd. mysqlnd has no isuses here.

If you insist on using the MySQL Client Library (libmysql) I strongly recommend to use mysqli_stmt_store_result() when fetching geometry data using prepared statements. When streaming data, which is the default for prepared statements, ext/mysqli will have to make a guess on the size of the result buffer it needs. The guess is based on a length reported by the MySQL CLient Library (libmysql). The MySQL Client Library reports 4GB (!) for a POINT - a conservative and safe guess. Consequently, ext/mysqli will try to allocate 4GB of RAM. The true (maximum) size of the column is not available before buffering the result on the client using mysqli_stmt_store_result(). If you call mysqli_stmt_store_result(), the result buffers will not get bigger than needed. However, store_result()/buffering is usually not what you want when you ask for prepared statements.

1 files changed, 2 insertions, 2 deletions

diff --git a/ext/mysqli/tests/mysqli_stmt_fetch_geom.phpt b/ext/mysqli/tests/mysqli_stmt_fetch_geom.phpt
index 7d7ef79f30..fc9cc64a7f 100644
--- a/ext/mysqli/tests/mysqli_stmt_fetch_geom.phpt
+++ b/ext/mysqli/tests/mysqli_stmt_fetch_geom.phpt
@@ -45,7 +45,7 @@ mysqli_stmt_fetch - geometry / spatial types
 			return false;
 		}
 
-		if (!mysqli_stmt_execute($stmt)) {
+		if (!mysqli_stmt_execute($stmt) || !mysqli_stmt_store_result($stmt)) {
 			printf("[%04d] [%d] %s\n", $offset + 8, mysqli_stmt_errno($stmt), mysqli_stmt_error($stmt));
 			mysqli_stmt_close($stmt);
 			return false;
@@ -65,7 +65,7 @@ mysqli_stmt_fetch - geometry / spatial types
 
 		$num = 0;
 		$rows = array();
-		while (true === mysqli_stmt_fetch($stmt)) {
+		while (true === @mysqli_stmt_fetch($stmt)) {
 			$rows[] = array('id' => $id, 'label' => $bind_res);
 			$num++;
 		}