Apologies, in respect of point 1 in my reply, I misread your original message and didn't realise you were referring to the upcoming 8.1 change, thought you were referring to the current 8.0.1 release.
This change AFAIK only affects emulated prepares and is an improvement, as previously you needed to have emulation off to get the correct data types. With modern PHP, MySQL and mysqnd there is not really a reason for anyone to be using emulated prepares anyway so my advice on points 2-5 remains the same. Dave On Sat, Feb 27, 2021 at 12:55 PM Stephen Reay <php-li...@koalephant.com> wrote: > > > On 27 Feb 2021, at 15:56, Matty The Mad <ma...@themad.com.au> wrote: > > > > 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > I agree it should be configurable, but storing digit strings as integers > is asking for trouble. > > Edit: Whoops, sending again from on-list address. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
