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

From: Date: Thu, 24 Mar 2011 12:03:40 +0000
Subject: Doc #49357 [Tbd->Csd]: MySQLi extension fails to recognize POINT (spatial) colums
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-6137@lists.php.net to get a copy of this message
Edit report at http://bugs.php.net/bug.php?id=49357&edit=1 ID: 49357 Updated by: abedford@php.net Reported by: phpbug at r-o-b-e-r-t dot de Summary: MySQLi extension fails to recognize POINT (spatial) colums -Status: To be documented +Status: Closed Type: Documentation Problem Package: MySQLi related Operating System: Debian/Ubuntu/Gentoo PHP Version: 5.2.10 Assigned To: abedford Block user comment: N Private report: N New Comment: Have updated the mysqli docs with a new notes section detailing differences between mysqlnd and libmysql when handling GEOMETRY types. Previous Comments: ------------------------------------------------------------------------ [2011-01-06 15:30:18] uw@php.net Tony, could you document it? Thanks! ------------------------------------------------------------------------ [2009-09-14 16:27:59] uw@php.net 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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49357 -- Edit this bug report at http://bugs.php.net/bug.php?id=49357&edit=1

« previous php.doc.bugs (#6137) next »