|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #49357 MySQLi extension fails to recognize POINT (spatial) colums
Submitted: 2009-08-25 14:55 UTC Modified: 2011-03-24 13:03 UTC
From: phpbug at r-o-b-e-r-t dot de Assigned: abedford (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.2.10 OS: Debian/Ubuntu/Gentoo
Private report: No CVE-ID: None
 [2009-08-25 14:55 UTC] phpbug at r-o-b-e-r-t dot de
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:
 `coord` point default NULL,

The Test Code:

// $mysqli is an existing db connection

$stmt = $mysqli->prepare("SELECT coord FROM user");
while ($stmt->fetch() === true ) {

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 refcount(1)
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-25 20:01 UTC] 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.



 - Robert
 [2009-08-26 10:34 UTC]
Works with mysqlnd, fails with libmysql. Missing type in mysqli_api.c:

@@ -373,6 +373,9 @@
                        case MYSQL_TYPE_NEWDECIMAL:
+                       case MYSQL_TYPE_GEOMETRY:

 [2009-09-11 13:38 UTC]
Automatic comment from SVN on behalf of uw
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-09-14 16:27 UTC]
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.
 [2010-12-25 13:43 UTC]
-Type: Bug +Type: Documentation Problem
 [2011-01-06 15:30 UTC]
-Assigned To: +Assigned To: abedford
 [2011-01-06 15:30 UTC]
Tony, could you document it? Thanks!
 [2011-03-24 13:03 UTC]
-Status: To be documented +Status: Closed
 [2011-03-24 13:03 UTC]
Have updated the mysqli docs with a new notes section detailing differences 
between mysqlnd and libmysql when handling GEOMETRY types.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Oct 02 19:03:43 2022 UTC