On Wed, Oct 1, 2025, at 15:55, Kamil Tekiela wrote: > On Wed, 1 Oct 2025 at 14:45, Robert Wolf <[email protected]> wrote: > > > > > I generally agree that there's little value to a disconnect() action; > > > unset($pdo) is already sufficient. > > > > See the point again about persistent connections. The user has no means to > > disconnect in that case. > > > > > I recommend to use a name that deters users from using it in normal > > > operations, e.g. pdo->debug_manual_disconnect(). > > > > Considering the above as well, a possible stance to take could be to > > introduce it as persistent_disconnect(). We could then decide whether it > > should function on "regular" connections as well. > > This sounds better, but I would argue that if it's a PERSISTENT > connection, then it should be impossible for the user to close it. The > idea is that the connection should remain open after being established > and should only close when the server restarts. What scenario would > necessitate the user to close a connection that should never close?
Off the top of my head (and it depends on the actual database on the other end of the pipe): 1. After grant/role revocation, password rotation, or a switch from read/write replicas. Existing sessions usually keep there their privileges in a lot of databases. So, you could argue this is a security issue for long-lived applications. 2. Perhaps you want to free any and all advisory locks? 3. Sometimes the handle is alive, but the network connection is dead (this is argued elsewhere though). 4. I've had some fun bugs in the past with prepared statements crashing a db server (putting it in maintenance mode and serving no traffic) being shared between requests. If I could have slapped a "just close it until we figure out what is going on" statement in there, I would have. 5. Replica promotion, primary failover, blue/green cutovers, firewall changes ... all these need new connections. Right now, you have to jump through a number of hoops to do these types of operations. — Rob
