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
Block user comment: N
Private report: N
New Comment:
> 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)
(
)
?>
Previous Comments:
------------------------------------------------------------------------
[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).
------------------------------------------------------------------------
[2016-12-04 14:26:48] spam2 at rhsoft dot net
Description:
------------
declare(strict_types=1); is nice but not helpful when you get from sql-queries *anything* as string
and so need to use (int)$row['id_where_i_know_db_type']
on the database server you have int, longint, smallint, tinyint which are clearly int - but why is
that information lost and anything casted to a string?
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=73650&edit=1
Thread (10 messages)