Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130084
Precedence: list
MIME-Version: 1.0
References: <CAGBsUrcKTcCzf5k_tGbk=cr02NrsEKPE=Y+CeSOqMrrdjKFftg@mail.gmail.com>
 <CAGBsUrePjfY6UrkTpV5c1jgZw0jwBmyf+mnFG-AAUJzMmeweAw@mail.gmail.com> <22fa6377fe0df3afe29fcc332108ba07@bastelstu.be>
In-Reply-To: <22fa6377fe0df3afe29fcc332108ba07@bastelstu.be>
Date: Tue, 17 Feb 2026 13:53:20 +0000
Message-ID: <CAGBsUreUw2mrJahqhnOnPGOMKUetUSz=0AzL8D=NPb60Ro71Jg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] New function mysqli_quote_string
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tekiela246@gmail.com (Kamil Tekiela)

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=C3=BCsterhus <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 =E2=80=9CVoting Choice=
s=E2=80=9D
> 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=C3=BCsterhus