Hello,
I would like to open a discussion about adding a new function to PHP
Would you support such an addition?
Regards,
Kamil Tekiela
Hi Kamil,
Il 18/12/2025 22:03, Kamil Tekiela ha scritto:
Hello,
I would like to open a discussion about adding a new function to PHP
Would you support such an addition?
I agree with you and I prefer PDO::quote()'s behaviour over the "old" non-pdo quote functions.
However, I also think that manually interpolating parameters is not a best practice that we should encourage: query parameters are the a much better defence against SQL injections.
Also I'm afraid that offering two alternatives would increase the confusion, especially if this new function is added only to mysqli and not other prominent database extensions.
Cheers
--
Matteo
On Fri, 19 Dec 2025 at 13:52, Matteo Beccati <php@beccati.com> wrote:
Hi Kamil,
Il 18/12/2025 22:03, Kamil Tekiela ha scritto:
> Hello,
>
> I would like to open a discussion about adding a new function to PHP
>
> PHP: rfc:mysqli_quote_string
>
> Would you support such an addition?I agree with you and I prefer PDO::quote()'s behaviour over the "old"
non-pdo quote functions.However, I also think that manually interpolating parameters is not a
best practice that we should encourage: query parameters are the a much
better defence against SQL injections.Also I'm afraid that offering two alternatives would increase the
confusion, especially if this new function is added only to mysqli and
not other prominent database extensions.Cheers
--
Matteo
Hi Mateo,
The new function isn't meant to encourage this practice. My RFC
acknowledges that query parameters are the best, but unfortunately,
manual escaping is a must for certain applications.
What other extensions do you have in mind? PDO already has it, so does
PostgreSQL with pg_escape_literal(). Every extension is different and
they never have the exact same functions. In fact, what I am proposing
is to bring mysqli in line with other extensions which already have
it.
The confusion it's going to cause is minimal. The behaviour is exactly
the same as the old function, just that the quotation marks are added
automatically. It's not rocket science.
Regards,
Kamil
On Fri, 19 Dec 2025 at 15:26, Kamil Tekiela <tekiela246@gmail.com> wrote:
On Fri, 19 Dec 2025 at 13:52, Matteo Beccati <php@beccati.com> wrote:
Hi Kamil,
Il 18/12/2025 22:03, Kamil Tekiela ha scritto:
Hello,
I would like to open a discussion about adding a new function to PHP
https://wiki.php.net/rfc/mysqli_quote_string
Would you support such an addition?
I agree with you and I prefer PDO::quote()'s behaviour over the “old”
non-pdo quote functions.However, I also think that manually interpolating parameters is not a
best practice that we should encourage: query parameters are the a much
better defence against SQL injections.Also I’m afraid that offering two alternatives would increase the
confusion, especially if this new function is added only to mysqli and
not other prominent database extensions.Cheers
Matteo
Hi Mateo,
The new function isn’t meant to encourage this practice. My RFC
acknowledges that query parameters are the best, but unfortunately,
manual escaping is a must for certain applications.What other extensions do you have in mind? PDO already has it, so does
PostgreSQL with pg_escape_literal(). Every extension is different and
they never have the exact same functions. In fact, what I am proposing
is to bring mysqli in line with other extensions which already have
it.The confusion it’s going to cause is minimal. The behaviour is exactly
the same as the old function, just that the quotation marks are added
automatically. It’s not rocket science.Regards,
Kamil
btw pg_escape_literal is mis-named. it does not escape - it quotes.
And there is an important difference between escaping and quoting,
at least for SQLite, it is impossible to make a binary-safe escape() function,
but it’s fully possible to make a binary-safe quote() function
(see https://github.com/php/php-src/pull/13972 )
IMO pg_escape_literal should be renamed pg_quote_literal.
On 2025-12-20 04:09, Hans Henrik Bergan wrote:
btw pg_escape_literal is mis-named. it does not escape - it quotes.
And there is an important difference between escaping and quoting,
at least for SQLite, it is impossible to make a binary-safe escape() function,
but it's fully possible to make a binary-safe quote() function
(see SQLite pdo::quote use ('foo'||x'0000'||'bar') for null bytes by divinity76 · Pull Request #13972 · php/php-src · GitHub <php.net · GitHub php-src/pull/13972> )IMO pg_escape_literal should be renamed pg_quote_literal.
>
quote_literal() is how PostgreSQL itself names the function, and it would be consistent with PHP's functions being named to reflect those that it wraps (à la mysqli_real_escape_string()).
Instead, I think it got called pg_escape_string() by symmetry with mysql_escape_string().
Hey Kamil, Matteo,
I initially looked at the mail by Kamil, and thought this was about quoting, to which I told myself “fine, that’s useful”.
After reviewing the contents, plus Matteo’s response, it is clear to me that this is another attempt at escaping aimed at string interpolation.
I’d be opposed to that, even just for the fact that we’re adding more tools to a toolbox that should instead point at prepared statements.
Projects like PHPMyAdmin have vast experience in handling this sort of API, and they should just do it themselves. BTW, it would be interesting to show exactly (in the RFC text) why/where these projects can’t use prepared statements.
If you were to propose something about quoting (with the correct backtick syntax, perhaps even based on the current set SQL compatibility mode), then that could be marginally interesting.
Greets,
btw pg_escape_literal is mis-named. it does not escape - it quotes.
And there is an important difference between escaping and quoting,
at least for SQLite, it is impossible to make a binary-safe escape() function,
but it’s fully possible to make a binary-safe quote() function(see https://github.com/php/php-src/pull/13972 )
IMO pg_escape_literal should be renamed pg_quote_literal.
A deviation, but this triggers my naming concern with preg_quote(). It doesn’t quote anything, it escapes things; and it should be able to process an array of strings! I dream of a future with a robust preg_escape() in it.
mickmackusa
Hi,
Il 19/12/2025 15:23, Kamil Tekiela ha scritto:
The new function isn't meant to encourage this practice. My RFC
acknowledges that query parameters are the best, but unfortunately,
manual escaping is a must for certain applications.
Such application are certainly capable of adding single quotes? I don't think we really need to spoon-feed them with a brand new function after 25+ years everybody and their dog has been using real_escape_string().
What other extensions do you have in mind? PDO already has it, so does
PostgreSQL with pg_escape_literal(). Every extension is different and
they never have the exact same functions. In fact, what I am proposing
is to bring mysqli in line with other extensions which already have
it.
Apologies, I was referring to pg_escape_string(), which I had used back in the days. I didn't recall pg_escape_literal + identifier: they have been added 14 years ago and they are using the underlying libpq PQEscapeLiteral and PQEscapeIdentifier functionality to offer even better / safer escaping.
Also ext/sqlite3 offers a non-binary safe escape function without quotes.
The confusion it's going to cause is minimal. The behaviour is exactly
the same as the old function, just that the quotation marks are added
automatically. It's not rocket science.
I agree it's not rocket science to do add **single quotes**. Saying that we need to do that in core to avoid users "accidentally forgetting the quotation marks" seems a bit of an overstatement. If they had forgotten the quotes, most of the times the query would error out rather than silently working and allowing SQL-injection.
As for single quotes vs other quote flavours, I reckon it should be documentation material, perhaps with a big yellow box like we do for charsets.
Cheers
--
Matteo
Hi Marco,
Il 19/12/2025 23:45, Marco Pivetta ha scritto:
If you were to propose something about quoting (with the correct backtick syntax, perhaps even based on the current set SQL compatibility mode), then that could be marginally interesting.
If you meant quoting identifiers, I'd be all for it. In fact my New Year's resolution would be an RFC to add a PDO::quoteIdentifier method.
Cheers
--
Matteo
On 20 Dec 2025, at 07:49, Matteo Beccati <php@beccati.com> wrote:
[...] Saying that we need to do that in core to avoid users "accidentally forgetting the quotation marks" seems a bit of an overstatement. If they had forgotten the quotes, most of the times the query would error out rather than silently working and allowing SQL-injection.
I wish most of the time it would error... exhibit A, found a couple of weeks ago.
$db->query('SELECT name FROM user WHERE id = ' . $db->real_escape_string($_GET['id']));
Just as an aside, Kamil, I like your proposal; while I hope that one day parameterised queries are used by everyone, we still live in a world where developers escape values themselves, and your proposal would reduce the chance of them making mistakes.
Craig
On Thu, 18 Dec 2025 at 21:03, Kamil Tekiela <tekiela246@gmail.com> wrote:
Hello,
I would like to open a discussion about adding a new function to PHP
Would you support such an addition?
Regards,
Kamil Tekiela
Hi All,
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.
Matteo said:
I agree it's not rocket science to do add single quotes. Saying that
we need to do that in core to avoid users "accidentally forgetting the
quotation marks" seems a bit of an overstatement. If they had forgotten
the quotes, most of the times the query would error out rather than
silently working and allowing SQL-injection.
I don't want people to focus on the wrong part of the RFC. It's not
just about forgetting quotes. That is a problem the developer would
introduce themselves and is usually easily noticeable. The trouble is
when the user uses double quotes and thinks that everything is ok. The
main reason for this RFC is to provide SQL-injection safe function for
manual escaping of strings. The existing function leads users into a
false sense of security, as even when the data is escaped and quoted
in double quotes, it remains vulnerable to SQL injection. Putting a
warning into the PHP manual is certainly a good idea, but we could
provide a fixed function and help users even more.
It paints PHP in a bad light when we ask users to add quotation marks
manually around the return value of a function that should do it
automatically, and then we put a warning in the PHP manual saying that
while double quotes would work too, they are not SQL injection safe.
Why can't PHP just provide a function that wraps it in the correct
quotation marks instead?
Regards,
Kamil
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): policies/feature-proposals.rst at main · php/policies · GitHub
Best regards
Tim Düsterhus