Bug #73650 [Opn]: why lose sql-results their type in PHP?

Edit report at https://bugs.php.net/bug.php?id=73650&edit=1 ID: 73650 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: why lose sql-results their type in PHP? Status: Open Type: Bug Package: *Database Functions -PHP Version: 7.0.13 +PHP Version: 7.0.14 Block user comment: N Private report: N New Comment: > PHP's int is only signed 32 bits int under 32 bit architecture show me the machines running in 2016 PHP70/PHP71 under a 32 bit architecture *and* then using declare(strict_types=1); - frankly linux distributions are stopping to build any 32bit stuff at all - there is no RHEL7 even while it ships PHP5.4 how many decades should we accept a doezen potential 32 bit machines stop envolving things? when i develop in strict mode and store a integer to mysql i excpect to get that integer back and not a random string which i have to cast manually or the whole strict_types is pointless because it only leads to fatal errors for no good reasons or you have to use (int) everywhere when something might have came from a database which makes any benefit of typing pointless Previous Comments: ------------------------------------------------------------------------ [2016-12-08 19:26:18] cmb@php.net If there is any chance, that an integer retrieved from a database won't fit into a PHP int, the proper way to deal with this would be something like: <?php if ($row['id'] >= PHP_INT_MIN && $row['id'] <= PHP_INT_MAX) { foo((int) $row['id']); } else { // uhm, we can't cast $row['id'] to int … } ------------------------------------------------------------------------ [2016-12-08 19:06:04] spam2 at rhsoft dot net > Integers in database may not match PHP internal > date types. e.g. PHP's int is only signed 32 bits > int under 32 bit architecture but how is that different to $row['id'] = (int)$row['id'] which you now must do manually becaus eotherwise sooner or later a function in a class with declare(strict_types=1); will end in a fatal error? __________________________ inlcude('functions.php'); $row = mysqli_fetch_result($result); foo($row['id']); is a fatal error currently without foo((int)$row['id']) __________________________ functions.php: <?php declare(strict_types=1); function foo(int $id) ( ) ?> ------------------------------------------------------------------------ [2016-12-05 01:26:28] yohgaki@php.net Not only DBMS, but also almost all inputs are "string". Converting types to appropriate one could be convenient, so I wrote a RFC for it. https://wiki.php.net/rfc/introduce-type-affinity The RFC isn't intended to use with database inputs, but this kind of feature may be useful if feature supports some kind of "schema". ------------------------------------------------------------------------ [2016-12-05 01:20:38] yohgaki@php.net Automatic type conversions do harm more than good. Integers in database may not match PHP internal date types. e.g. PHP's int is only signed 32 bits int under 32 bit architecture. Database's INT8 could unsigned with MySQL/etc. SQLite's type is pseudo type and could be any text even when columns are defined as int/etc. Converting other system's types to PHP type should not be automatic, but manual. We shouldn't do the same mistake done in JSON again. I'm against to have broken automatic type conversions. That said, I don't oppose to develop workable type conversion framework. ------------------------------------------------------------------------ [2016-12-04 22:12:09] cmb@php.net I've changed the package to "Database Functions", even though not all database extensions are working this way, see <https://3v4l.org/07TWk>. And I don't think this is a bug – it's rather something that could be improved. Note that there are some issues, however. Cf. <https://3v4l.org/H1Sel>, for instance (the result could also be a string, but not an int, as the value overflows 64bit signed integers). ------------------------------------------------------------------------ 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=73650 -- Edit this bug report at https://bugs.php.net/bug.php?id=73650&edit=1