Edit report at https://bugs.php.net/bug.php?id=72798&edit=1
ID: 72798
Updated by: nikic@php.net
Reported by: php dot chaska at xoxy dot net
Summary: SELECT COUNT() returns string, not int.
-Status: Analyzed
+Status: Closed
Type: Bug
Package: PDO SQLite
Operating System: FreeBSD, Mac OSX
PHP Version: 5.6.24
-Assigned To:
+Assigned To: nikic
Block user comment: N
Private report: N
New Comment:
Bug #38334 has been fixed in PHP 8.1, so the SELECT COUNT(*) case will now return an integer as well
(unless stringification was requested of course).
Previous Comments:
------------------------------------------------------------------------
[2016-08-10 11:29:06] yohgaki@php.net
However, I don't object strongly, if this is the PDO way should be :)
------------------------------------------------------------------------
[2016-08-10 11:25:16] yohgaki@php.net
Even with 64 bit systems, we have issues. Signedness is issue.
For instance, I have code that store 64 bits hash value and stored into unsigned int64 database
field. Since PHP's int is signed, conversion will have unwanted result unless I use sprintf().
i.e.
$hash == $hash_val_stored_in_db
cannot evaluated as the same value because of signed int...
PostgreSQL's int64 is always signed, but MySQL int64 could be unsigned for instance.
------------------------------------------------------------------------
[2016-08-10 10:15:00] cmb@php.net
On x86 builds (which are still distributed), however:
PHP_INT_MAX === 2147483647
------------------------------------------------------------------------
[2016-08-10 09:59:23] kalle@php.net
@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.
------------------------------------------------------------------------
[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>
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=72798
--
Edit this bug report at https://bugs.php.net/bug.php?id=72798&edit=1