Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116730 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58130 invoked from network); 24 Dec 2021 16:28:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Dec 2021 16:28:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 542B61804C3 for ; Fri, 24 Dec 2021 09:33:01 -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.1 required=5.0 tests=BAYES_40,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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 ; Fri, 24 Dec 2021 09:33:00 -0800 (PST) Received: by mail-qt1-f182.google.com with SMTP id l17so8090514qtk.7 for ; Fri, 24 Dec 2021 09:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=2mWauqoYCMC1krL2KkydPzuEI2sSpDcFMdmkzy1RSpo=; b=Bx8b6YffkpZFHccFJd+MQ3B9A/PYrEEhPGPMN1H4V2RLuwDxw+wdd2G5/YkD3Ndbr5 VnSC4jQb7ouSDKE0Mpn2bPcg7CIItNogq+Gy+OEHbUwVe7cuBF7zYsHgeqlOUJgd0eku sFl8y2QUkqlfxmFsgN0OlI7Wz9DHNDaliRUdr7dMOkv67bFj9nRkBlvpgBDzPFAWiriY dHGh9PlUCUdPT+7wVdqSwrOHUwKG1bQtxWY8+VodLz/sVyJ+ZQSUoycWkOfBl1ehJ30u VlsddlCRsC7mn4me1vsozytHJNhxtVEpC3Nj91kGHmakJf7LFU8kkPMpqgCaztWI/K/b jKNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2mWauqoYCMC1krL2KkydPzuEI2sSpDcFMdmkzy1RSpo=; b=AWfzMzqMfVmBIwwun0pdyQmgaDCXKn83fG/1IxcYjVEKDnK+moUyxAL15xggYRy/hv Sli2HuJdsEOMl/xfhL6SsZ9bZtw4SoqgYfA+WQrtgsul2jF9RmdrL7lId7Dei+dfOk7+ I06QzsBTZAQMNufWLo/uupmXeIX3uGpwtUunqndnv35I9ek64hF5awTnxKsf2BdO5I22 DOLk3yUKff4RR4+CnMriCT75L9C2WQDSCYBCi0D7pCZjf6ftIrM6wpTuS17qyzbkNawf fvtUuV3/qSahxDf0sN+zmfypefoeBEckjpId0vh2FwfqoFoUhIT39Ggzh5jdFkBM1/y6 2YSw== X-Gm-Message-State: AOAM533Yew+U7L1oKdpa5qMaKqTydwv+aye6lVkPnAPuhmwk1/201GX+ 7glPY6OE49f9ioqfuwNV6iUrPB2HY6bxyDliMtP9oy01GyM= X-Google-Smtp-Source: ABdhPJy3xzO1bBmX24Yreur+e196IvKYmtrC2FXH6KEO8zqBRc0EnmZzrvqPPpYsSm9k7iTRAZaxqI/uRF7LdmUBDJc= X-Received: by 2002:a05:622a:d5:: with SMTP id p21mr5079209qtw.518.1640367179748; Fri, 24 Dec 2021 09:32:59 -0800 (PST) MIME-Version: 1.0 Date: Fri, 24 Dec 2021 17:32:49 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000000cd68b05d3e7bf2f" Subject: Drop support for libmysql with mysqli From: tekiela246@gmail.com (Kamil Tekiela) --0000000000000cd68b05d3e7bf2f Content-Type: text/plain; charset="UTF-8" Hi Internals, I would like to propose dropping support for libmysql from mysqli and ask for opinions on how this could be best achieved. At the moment both mysqli and PDO_mysql support building against mysqlnd and libmysql. The default is mysqlnd since PHP 5.4. Mysqlnd is the recommended library to be used with PHP. There are plenty of differences between the two libraries. Removing support for libmysql would allow PHP to simplify the code and unit tests. Advantages of mysqlnd include: - Bundled with PHP - Uses PHP memory management which helps to monitor memory usage and improve performance - Provides functions that make life easier, e.g. get_result - Returns numeric values using PHP native types - The functionality does not depend on the version of the external library - Optional plugin functionality - Asynchronous queries Advantages of libmysql: - Auto-reconnect is possible (this functionality is intentionally not supported by mysqlnd due to how dangerous it is) However, libmysql has many disadvantages: - It does not use PHP memory model. It doesn't respect the memory limits, does not count towards memory stats and cannot utilize internal optimizations - PHP does not know the value size and needs to allocate as much memory as the field length. This makes it very difficult to use with long columns like LONGTEXT - Doesn't support get_result, bind-in-execute, and fetch_all & next_result (prior to PHP 8.1). This makes libmysql the smallest common denominator for applications like DBALs which can't rely on these easy to use functions and instead have to perform strange workarounds resulting in more complex code and worse performance, even when not using libmysql - Functionality differs from version to version. Depending on which libmysql version PHP was compiled with you might be able to use a certain feature or not. - Many failing tests. Some of these tests could be fixed with SKIP or conditional checks, but some fail because of incompatibilities. - Memory leaks. These might even be considered security vulnerabilities - Not available on Windows While many distributions offer PHP with mysqlnd as default there are some that make it confusing for new users. In particular, when using cPanel, users are confused about how to enable mysqli with mysqlnd. Instead of enabling mysqli they have to enable nd_mysqli extension which is counterintuitive. In 2019, Nikita suggested dropping the support or finding a maintainer for it [1]. So far, nobody has come forth to improve mysqli support with libmysql. It has become clear that there is not much demand for it. If people were using it, then someone would eventually fix the bugs. PHP doesn't have CI jobs and is not testing for the failing unit tests. We can consider mysqli with libmysql as not supported configuration, but that leaves us with the problem that PHP still makes it possible to compile with libmysql and the PHP manual list it as a viable option. I would propose to drop the support for mysqli with libmysql, but it would be nice to do it with a deprecation period. I am not sure if it is possible to have a deprecation period. If we raise a deprecation during compilation, users won't see it. If we raise it during usage, we will flood their error logs. I think we can keep support for libmysql with PDO_mysql as it has been fixed and seems to be working ok. I am not sure what benefit it brings, but if it doesn't harm then there's probably no reason to drop it. Certainly, we should encourage usage of mysqlnd with PDO as it should offer better performance and reliability. We don't control the version of libmysql used in the compilation process so while it works in CI jobs, it might not work 100% when used with other versions. e.g. MySQL's libmysql vs MariaDB's libmysql I am also looking to find out if anyone knows of any other advantages of mysqli with libmysql or is intentionally using mysqli with libmysql in their production systems. [1]: https://externals.io/message/106086 Further reading: https://externals.io/message/55084 Kind Regards, Kamil Tekiela --0000000000000cd68b05d3e7bf2f--