Re: [PHP-DEV] [RFC] [VOTE] Minimum supported versions for PHP 8.6

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