Bug #72798 [ReO->Ana]: SELECT COUNT() returns string, not int.

From: Date: Wed, 10 Aug 2016 09:59:25 +0000
Subject: Bug #72798 [ReO->Ana]: SELECT COUNT() returns string, not int.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-203139@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72798&edit=1 ID: 72798 Updated by: kalle@php.net Reported by: php dot chaska at xoxy dot net Summary: SELECT COUNT() returns string, not int. -Status: Re-Opened +Status: Analyzed Type: Bug Package: PDO SQLite Operating System: FreeBSD, Mac OSX PHP Version: 5.6.24 Block user comment: N Private report: N New Comment: @yohgaki well in 7.0+, we have a much better and more reliant 64 bit system implemented, and I think that at least on Windows we would make PHP's int always 64 bit, and have a way to emulate that, and I don't see a reason why we cannot reliably convert to a PHP int if we can guarantee that PHP's int always will be at mimimum 64 bit. As for the 128 bit part, I expect us to support 128 bit as other database systems and hardware decides to adopt that, so I don't forsee that as an issue. Previous Comments: ------------------------------------------------------------------------ [2016-08-10 09:51:09] cmb@php.net > Automatic conversion is OK only when external numeric value and > PHP type is 100% compatible. Therefore, conversion must not be > automatic, but manual. Otherwise, programs lose data or > misbehave. IMHO, it is better to do the conversion internally, if and only if it is lossless (like sqlite_value_to_zval() does). Otherwise the burden of proper conversion is up to the userland developer, who might easily just do a simple (int) $val, what would be wrong, see <https://3v4l.org/jgO2M>. With ext/sqlite3 the dev could rely on a simple is_int($val) instead of `$val <= PHP_INT_MAX && $val >= PHP_INT_MIN or filter_var($val, FILTER_VALIDATE_INT) !== false`. Anyhow, the behavior of the different PDO drivers should be adjusted to match each other. Doing otherwise, would somehow defeat the the purpose of having PDO[1] (emphasis mine): > The PHP Data Objects (PDO) extension defines a lightweight, > *consistent* interface for accessing databases in PHP. [1] <http://php.net/manual/en/intro.pdo.php> ------------------------------------------------------------------------ [2016-08-09 21:40:27] yohgaki@php.net External numeric values must not be converted to PHP (or any other language) types automatically. Automatic conversion is OK only when external numeric value and PHP type is 100% compatible. Therefore, conversion must not be automatic, but manual. Otherwise, programs lose data or misbehave. We've seen this kind of problems in DB, XML, JSON, etc already and should not create no more problems. ------------------------------------------------------------------------ [2016-08-09 21:27:31] yohgaki@php.net Numeric values MUST NOT be converted to PHP types. It just don't work. Int could be 32 or 64 bits (+ signedness). It may be 32, 64 or 128 bits in near future. ------------------------------------------------------------------------ [2016-08-09 20:00:56] cmb@php.net I can confirm this behavior for other queries as well, see <https://3v4l.org/bh03r>. Actually, this report is a duplicate of request #38334, but I do not really agree with the mentioned reasoning that "SQLite by its nature is a typeless database, […]". SQLite3 supports manifest typing[1], what is not typeless; otherwise one may claim that PHP would be also typeless. And, for what it's worth, ext/sqlite3 returns an int from the same query, see <https://3v4l.org/hiPXa#v560>. It shouldn't be too hard to add something like sqlite_value_to_zval() to PDO_SQLite. [1] <http://sqlite.org/different.html#typing> [2] <https://github.com/php/php-src/blob/PHP-7.0.10/ext/sqlite3/sqlite3.c#L580-L608> ------------------------------------------------------------------------ [2016-08-09 19:12:05] php dot chaska at xoxy dot net Description: ------------ --- From manual page: http://www.php.net/pdostatement.fetchcolumn --- With this SQL statement SELECT count(*) FROM my_table; fetchColumn() returns an INTEGER with Postgres and a STRING with Sqlite. That is, if there is one row in the table, Postgres returns (int)1 and Sqlite returns '1'. Note that SELECT TYPEOF(b) FROM ( select count(*) as b from my_table) a; produces integer in Sqlite. See also http://stackoverflow.com/questions/38857255/php-pdo-postgres-versus-sqlite-column-type-for-count Test script: --------------- http://pastebin.com/arGpxjm7 Expected result: ---------------- I expect both Postgres and Sqlite to return an integer type from fetchColumn() in both cases, since that is what the database claims it is returning. That is, I expect this result from my test script: Postgres: int(1) Sqlite3: int(1) Actual result: -------------- Postgres: int(1) Sqlite3: string(1) "1" ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=72798&edit=1

« previous php.bugs (#203139) next »