Re: Re: [RFC] New function mysqli_quote_string

From: Date: Tue, 17 Feb 2026 13:53:20 +0000
Subject: Re: Re: [RFC] New function mysqli_quote_string
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-130084@lists.php.net to get a copy of this message
Hi All, If there are no objections, I am planning to start the voting on this RFC over the weekend. Regards, Kamil On Fri, 9 Jan 2026 at 10:55, Tim Düsterhus <tim@bastelstu.be> wrote: > > Hi > > Am 2026-01-08 21:43, schrieb Kamil Tekiela: > > Despite receiving some criticism, I would like to bring it to a vote > > still. > > > > If this method doesn't get added, then it means that this SQL > > injection vulnerability will never be patched. Sure, most users have > > probably switched to prepared statements and we should encourage > > others to do so, but as long as manual escaping exists, it should be > > reliable and not prone to hidden SQL injection. > > I'm in favor. It's a localized addition with a clear purpose and > value-add, a good name and precedent in related extensions. I'm also in > favor of using deprecations to steer users away from unsafe APIs - even > when the functionality in question will never be removed. Unfortunately > getting those voted in is complicated, I've had my fair share of > experience with that in the past few PHP versions. But I agree that the > deprecation must not happen in the same version where the replacement is > added, since this makes incremental roll-outs of the new PHP version > annoying since there is no version of the code base that is cleanly > supported by both PHP versions. > > With regard to the RFC itself: Please clean up the “Voting Choices” > section, including properly filling in the vote title. The latter then > triggers a 14 day cooldown (since changes to the voting widgets are > Major changes): > > https://github.com/php/policies/blob/main/feature-proposals.rst#types-of-changes > > Best regards > Tim Düsterhus

« previous php.internals (#130084) next »