Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113294 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 13223 invoked from network); 27 Feb 2021 09:00:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2021 09:00:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 399461804D0 for ; Sat, 27 Feb 2021 00:49:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [5.45.198.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 27 Feb 2021 00:49:50 -0800 (PST) Received: from iva8-47ced5cdacc3.qloud-c.yandex.net (iva8-47ced5cdacc3.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:d90:0:640:47ce:d5cd]) by forward104j.mail.yandex.net (Yandex) with ESMTP id EFDFC4A0BF7 for ; Sat, 27 Feb 2021 11:49:47 +0300 (MSK) Received: from iva5-057a0d1fbbd8.qloud-c.yandex.net (iva5-057a0d1fbbd8.qloud-c.yandex.net [2a02:6b8:c0c:7f1c:0:640:57a:d1f]) by iva8-47ced5cdacc3.qloud-c.yandex.net (mxback/Yandex) with ESMTP id kBanMHoa1x-nlHmcfw2; Sat, 27 Feb 2021 11:49:47 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themad.com.au; s=mail; t=1614415787; bh=7atYjb4PA3ZwQ+9wQyvKSbHrpa2cQg8HJgIqpY+qCUo=; h=Subject:From:To:Message-ID:Date; b=XdrLH9khvXkLjV82x7J36GBse2GOqXfwTKSce+RXqDd8k/36rXCJUayKJJ8FCQgaC +8EZgiUJs+pT6ENfKzbH80IegSz/IAuqe83SLCs6AjOR56/FACrcv1ZjPR8q+r7BNC GAq/kt+MTgYrILTEhdfv2y+cySIW+4tlBjsfTlQc= Authentication-Results: iva8-47ced5cdacc3.qloud-c.yandex.net; dkim=pass header.i=@themad.com.au Received: by iva5-057a0d1fbbd8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id rSeZWtyonW-njJmFBEL; Sat, 27 Feb 2021 11:49:46 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) To: internals@lists.php.net Message-ID: <499c2591-fb11-1b9d-d402-39f7ec1c6b85@themad.com.au> Date: Sat, 27 Feb 2021 18:49:43 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: PDO integer changes in 8.1 will stop many websites I support From: matty@themad.com.au (Matty The Mad) PHP 8.1 PDO has been changed so that when MySQL returns an integer it will no longer be returned as a string, but as an int. The problem is this breaks any sites that use UNSIGNED ZEROFILL integer fields in MySQL. I support a number of websites where the phone numbers and post codes are all UNSIGNED ZEROFILL. The post codes in MySQL are stored as 0800. In PHP 8.0 returned as string 0800 In PHP 8.1 returned as integer 800 8.0.2 string(10) "0742000000" 8.1.0-dev int(742000000) PDO shouldn't really be changing the data. I propose that: • any ZEROFILL integers are returned as string [or] • there's an option to control this when making the connection (I don't want to str_pad() at every place I've used ZEROFILL in the past) [or] • this backwards compatibility breaking change is removed until PHP 9. Matthew Asia