Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129786
Precedence: list
MIME-Version: 1.0
References: <CAPUh_1bK6VrODocLUNUoz+GCHGFqddrkVTEbA47RXXbpJAxB4A@mail.gmail.com>
 <CAGBsUrfbHfJYb1JPTAPXDPnmLj8zo=xjywC9VjaYQM0YO4CJFw@mail.gmail.com>
In-Reply-To: <CAGBsUrfbHfJYb1JPTAPXDPnmLj8zo=xjywC9VjaYQM0YO4CJFw@mail.gmail.com>
Date: Mon, 19 Jan 2026 15:27:09 +0300
Message-ID: <CAPUh_1Yd6h6fSAYafxPbD0_f2PSuKaoTG55OmGS+rf6V_7F54g@mail.gmail.com>
Subject: Re: [PHP-DEV] Improving PDO persistent connections and event loop support
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: go.al.ni@gmail.com

> But there is a reason why mysqli allows for this feature to be
> switched off in the compilation options. Certain users do not like
> this.

I'm pretty sure this option introduced not by user demand. But
because maintainers thought it may be useful.

This should be opt in. Because backward compatibility, not
because someone disliked it. Can't imagine situations where
obtaining dirty connect from previous script execution would be
useful.

This may be implemented using pdo option:

```php
$db = new PDO(
  'dsn', 'user', 'password', [
    PDO::ATTR_PERSISTENT => true
    PDO::ATTR_AUTO_RESET_PERSISTENT => true,
  ]
);
```

> It is silently discarding errors and data, which could be
> disastrous in some situations.

That's exactly what I want - not bothering about errors and
data left from previous script.

>> PDO does not have method for closing connection.

> As I said in an earlier email, this is intentional. Such a method is
> a bad idea.

We have mysqli::close and this is ok. But PDO::close is a bad idea?
I don't understand.

> I stand by what I said before: in a well-designed
> application, there is absolutely no reason to close the connection
> explicitly.

Creating well-designed application is hard. As a creator of event loop
framework I can't be sure that every user of my framework is a superstar
in programming and application design. So I'd prefer to leave my users
with "crippled objects" that would fail-fast in the next loop iteration
instead of invisible db connection leak.

This is also very suitable for True Async RFC [1]. In that case if you
want send queries in parallel coroutines, then db connection pool should
be used. And for connection pool implementations it's mandatory to have
possibility to close db connection explicilty.

[1] https://wiki.php.net/rfc/true_async