#49357 [Ver->Tbd]: MySQLi extension fails to recognize POINT (spatial) colums

ID: 49357 Updated by: uw@php.net Reported By: phpbug at r-o-b-e-r-t dot de -Status: Verified +Status: To be documented Bug Type: MySQLi related Operating System: Debian/Ubuntu/Gentoo PHP Version: 5.2.10 Assigned To: mysql New Comment: This has been fixed in PHP 5_3 and trunk (PHP 6). Please note the SVN commit message. In the worst case ext/mysqli used together with the MySQL Client Library will allocate a huge result buffer of 4GB to hold as little as 25 bytes needed to represent a POINT(1, 1) in binary format. Previous Comments: ------------------------------------------------------------------------ [2009-09-11 13:38:48] svn@php.net Automatic comment from SVN on behalf of uw Revision: http://svn.php.net/viewvc/?view=revision&revision=288267 Log: 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. ------------------------------------------------------------------------ [2009-08-26 10:34:25] uw@php.net Works with mysqlnd, fails with libmysql. Missing type in mysqli_api.c: @@ -373,6 +373,9 @@ #ifdef FIELD_TYPE_NEWDECIMAL case MYSQL_TYPE_NEWDECIMAL: #endif +#ifdef FIELD_TYPE_GEOMETRY + case MYSQL_TYPE_GEOMETRY: +#endif ------------------------------------------------------------------------ [2009-08-25 20:01:02] bugs at r-o-b-e-r-t dot de Sorry for my double-posting of the same bug. But I got everytime an error, that the headers already was sent. So i tried several times to submit my bug, and did not recognize, that it was already submitted. SORRY!! regards - Robert ------------------------------------------------------------------------ [2009-08-25 14:55:11] phpbug at r-o-b-e-r-t dot de Description: ------------ As reported in Bug "#37671 MySQLi extension fails to recognize BIT colums" I have the same problem with a Spatial Column. The Column coord is a POINT Field. Reproduce code: --------------- Here is the Table-Definition: CREATE TABLE user ( coord point default NULL, ) ENGINE=InnoDB The Test Code: // $mysqli is an existing db connection $stmt = $mysqli->prepare("SELECT coord FROM user"); $stmt->execute(); $stmt->bind_result($res); while ($stmt->fetch() === true ) { debug_zval_dump($res); var_dump($res); } $stmt->close(); Expected result: ---------------- The binary representation of the point Actual result: -------------- The Output is the same as the BIT-Field Problem (#37671) Warning: mysqli_stmt::bind_result(): Server returned unknown type 255. Probably your client library is incompatible with the server version you use! in /home/robert/tmp/test.php on line 11 NULL refcount(1) NULL NULL refcount(1) NULL NULL refcount(1) NULL NULL refcount(1) NULL NULL refcount(1) NULL NULL refcount(1) NULL ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=49357&edit=1