On 2026-07-19 15:17, Tim Düsterhus wrote:
Hi
On 7/18/26 01:34, Eric Norris wrote:
I don't know if the cost is "just a few conditionals." We'd have two
paths with a PDO option:
[…]
I don't like either of these options, and as the RFC author I feel
that the best outcome is to choose the "correct" choice, especially
considering that we are talking about software that is a decade old.
While I can appreciate your argument, I don't think that the pool of
affected users is large enough to warrant anything less than this.
I agree with the entire quoted email, and particularly the last
paragraph. The “shared nothing” request model of PHP is a huge selling
point to make the code easy to reason about and prevent a whole class of
bugs. I would consider it a bug that persistent connection can introduce
mutable state that outlives a given request and thus supporting and
using COM_RESET_CONNECTION is a bugfix in spirit to me.
While I see your point that it's in "bugfix spirit" and I do belong to
the camp of those who'd never ever rely on the shared connection state,
we don't know how many applications there are that implicitly or
explicitly rely on that behavior that dates back to over 2 decades ago.
By implicit, I don't mean necessarily sharing temporary tables and SQL
variables.
For instance, MariaDB and MySQL appear to behave differently in response
to the reset; MariaDB changed it in 2019:
* https://bugs.mysql.com/bug.php?id=97633
* https://jira.mariadb.org/browse/MDEV-18281
So, which charset should one expect?
Other than that, nearly everywhere there's usually (I checked Java and
Python specifically) a method to reset a connection. I would argue PHP
should rather give a choice when to reset a connection by exposing a way
to execute the command at will and add a convenience layer of issuing
(or not issuing) it between processing the requests -- just because a
user could totally want a different reset behavior, their own one (which
they might have by now), just because `COM_RESET_CONNECTION` is no
silver bullet but rather an option.
I also find it a reasonable expectation from PHP users, and particularly
companies, that when they want to benefit from the latest and greatest
PHP that they also keep the rest of their stack current. For the
COM_RESET_CONNECTION case the only expectation is that they use a MySQL
or MariaDB version that is not EOL. In fact according to EU law such as
the GDPR, using software that is no longer supported by updates is
extremely risky, since it very likely contains known and unfixed
security vulnerabilities. My understanding is that there are other
compliance frameworks - such as PCI - that effectively mandate using
“maintained software” as well.
By no means do I think that this should not be introduced or using an
older database is a good practice. I'm sure, though, we can do better
that just add a command without giving the freedom of choice to a user,
and there's more to choose than just which version of the database to run.
Thanks,
Alex
