Bug #76639 [Com]: PDO throws PDOException for no apparent reason

Edit report at https://bugs.php.net/bug.php?id=76639&edit=1 ID: 76639 Comment by: maaaddog at gmx dot at Reported by: janssen dot rob at gmail dot com Summary: PDO throws PDOException for no apparent reason Status: Not a bug Type: Bug Package: PDO Core Operating System: SMP Debian 4.9.110-1 (2018-07-05 PHP Version: 7.2.7 Block user comment: N Private report: N New Comment: PHP/PDO's fetchAll() OVERWRITES result index when query has a fixed NUMBER as table row. DESCRIPTION =========== PHP/PDO fetchAll() extends the resulting array from a query by its column name. But when a column name is a NUMBER it OVERWRITES contents on that index number! When do problems occur? If you are faced with multiple queries unified by "UNION" sometimes it is necessary to set a row to a fixed number (e.g. to mark its origin): "SELECT Pid,0 FROM Person UNION SELECT Pid,1 FROM Company". EXAMPLE ======== Now when you put such a query (here just one) in PHP/PDO you may have: $stmt = $this->dbh->prepare("SELECT Pid,0 FROM Person"); $stmt->execute(); $rows = $stmt->fetchAll(); if (!empty($rows)) { foreach($rows as $row){ $pid = $row[0]; $num = $row[1]; } } When you debug the output by "print_r($rows)" you see that PHP/PDO extends the array retrieved by fetchAll() by its column names. So one can retrieve the data from it either by $row[i] or by $row[COLUMNNAME]. Now, when the column is a NUMBER it OVERWRITES the index an THAT number. In this case the second column is set to "0" and therefor it OVERWRITES row[0] where pids are stored. EXPECTED BEHAVIOR ================= 1,0 2,0 3,0 ... ACTUAL BEHAVIOR =============== 0,0 0,0 0,0 ... I have tested this on PHP 8.1.15 CGI/FastCGI (API:20210902) environment. But I have also tested it on my backup server (with other settings) where this also occurred. Previous Comments: ------------------------------------------------------------------------ [2018-07-19 15:16:53] requinix@php.net ...actually it is working but it doesn't process the bug description. I had never noticed that. ------------------------------------------------------------------------ [2018-07-19 15:15:10] requinix@php.net Looks like the automatic cross-referencing isn't working yet. Request #76647 ------------------------------------------------------------------------ [2018-07-19 15:14:09] requinix@php.net Just created the request. Decided on something separate so there's no need to read a few screenfuls of comments here to understand it. ------------------------------------------------------------------------ [2018-07-19 11:09:52] pmmaga@php.net That makes sense to me. But maybe it would be better to file a new request ticket? Otherwise feel free to reopen this. ------------------------------------------------------------------------ [2018-07-19 05:16:29] requinix@php.net > Unless you mean warning during the prepare. Mostly I'm aiming for a clearer error message - "Invalid parameter number" is a bit confusing when they're named. But yes, I think prepare() would be the best time for it: that's where the problem actually occurs and where it would be fixed by the user. ------------------------------------------------------------------------ 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=76639 -- Edit this bug report at https://bugs.php.net/bug.php?id=76639&edit=1