Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113317 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 79630 invoked from network); 27 Feb 2021 20:11:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2021 20:11:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 48E471804E4 for ; Sat, 27 Feb 2021 12:00:53 -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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 27 Feb 2021 12:00:52 -0800 (PST) Received: by mail-ej1-f41.google.com with SMTP id bm21so1930453ejb.4 for ; Sat, 27 Feb 2021 12:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gMsPfPFjSeOUa/jZ0iNe+L/MVfARSV9hTkVlcLdgnsw=; b=FjIEXLbubGZJLvli8F6DhN/45QmRD+eJ+PWRLDMpmygfIw5MU0z+0aiBoQYMn52w6m tuxEvPZjGZKXZucnvFk8les3k967iLSVAHpVkwAHSS4QiTmMUlwuGD7dEH0GC48PRmF0 2+q1bMz401+CQNeCWgY+uanZYStT5p06dJrCKcItKPXfVDETazyDGGvAmym4/UZD+7sF uDRDBauXd74fj670LK+1fdSk1X+XTcWFJlMhHQTEH+I06GabYEfr4Bo4KbZ1MFDWo6wn b+UkPMbGPjwvFTXIDVm1I0EiGwsZ/b6c7sCaHgn1LjLvPy/wN6R8plSov+g4thGlTeSA OXMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gMsPfPFjSeOUa/jZ0iNe+L/MVfARSV9hTkVlcLdgnsw=; b=hkiOs2hKnbzN/5w/vwa63HjLEHG8nenKDQ6VMvX6Op2MB1aAkLLtkfP5/FD7HP5E40 HcsOYvHt8DmmrcnZE7Zc4bmWYZ6HNL37ItsQ71OeSkYjLFpgEgKOCXjTJcIGb57rB8db 0Z1FN0hPy9h+H26UkCv/nLlZg0dXKz2tviVOke7HyaaW0o3fLIs4oA4iuURfsRvncoxl HmVddHAw0jmfLUtnKBalDrLH60EUQnHxVb/Hpcrrlce1aCPyrM7Snv/S4xA2vi8lq+rM TfJMredH3eOrSUeC+MIYqoTqp4tNCPK20ZmNYZJcNF8DtMRbFPCK5ryTqEPPfuFfYyNp vmjA== X-Gm-Message-State: AOAM531RHD0gHtX8cQu2AcZ2sndktTMePTn86WMpzPEGcHpxKdK5RZwi KyaKoPRpVUiqYXEUtHOMtpDZNQzzFx6Z4VJDVI8= X-Google-Smtp-Source: ABdhPJzsZTgyYvR60pmR+FrCDJAIHk7o/y+G2OpOqbnwJyC1A3GM/Bay8G+WD+HMqbW9JURXN9fc/nXXyVSkjno9VAI= X-Received: by 2002:a17:906:d71:: with SMTP id s17mr9470695ejh.126.1614456048576; Sat, 27 Feb 2021 12:00:48 -0800 (PST) MIME-Version: 1.0 References: <499c2591-fb11-1b9d-d402-39f7ec1c6b85@themad.com.au> <6EC89E9A-035D-4D2B-97D7-845DC4FF3E32@koalephant.com> <347e565f-f90a-5fc6-efcf-e28856ad00dc@gmail.com> <23cf71d2-4fed-ceab-6c63-c826af01bb36@processus.org> <06b75517-ecdd-c409-e6ca-3a7ed14fb628@gmail.com> In-Reply-To: <06b75517-ecdd-c409-e6ca-3a7ed14fb628@gmail.com> Date: Sat, 27 Feb 2021 20:00:37 +0000 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000047ea1905bc56d74c" Subject: Re: [PHP-DEV] PDO integer changes in 8.1 will stop many websites I support From: tekiela246@gmail.com (Kamil Tekiela) --00000000000047ea1905bc56d74c Content-Type: text/plain; charset="UTF-8" Hi Matthew, As was pointed out before ZEROFILL is getting deprecated. It has been deprecated by MySQL and I assume MariaDB will follow soon. The change you are referring to is only to fix inconsistency in PHP. The problem with ZEROFILL has been present since forever as far as I know. The setting PDO::ATTR_STRINGIFY_FETCHES is not going to affect the result either, because the value isn't stored with zeros. The length of integers columns only signifies how MySQL displays it in the result. Storing non-numerical values like phone numbers or zip codes in integer columns is just a terrible idea. If the zip code has a leading zero that is part of the data then it should be stored in a text column. MySQL doesn't store the leading zeros. It only pads the output. If you want you can always cast the number to a character SELECT CAST(`ZEROFILL` as CHAR) FROM `zerofill` which will tell MySQL to pad the output. The change that Nikita did is the correct one. As to whether PHP should do anything with regards to ZEROFILL_FLAG is a separate question. Re Pierre's confusion: I believe you are confusing prepared statements with emulation of prepared statements, but this is orthogonal to this discussion. Kind Regards, Kamil --00000000000047ea1905bc56d74c--