Hi Larry (and all), Sorry for the longer-than-usual reply, but I think a more complete answer now will help avoid misunderstandings down the road.
*== On the PSR-20 parallel ==* I want to address your point about PSR-20 first, because I think there is a fundamental misunderstanding about what this interface is meant to share. You described *PdoProviderInterface* as "a way to extract one service dependency from another service." That is not the intended use. The parallel with PSR-20 actually holds: just as every service that needs the current time is injected with a ClockInterface and calls now() repeatedly, every service that needs a database connection would be injected with a *PdoProviderInterface* and calls getConnection() each time it needs one. What is shared between services is the interface, not a \PDO instance. The provider behind the interface decides what getConnection() returns. It could be a lazy singleton, a reconnected instance, or a pooled connection. That is exactly the point. *== On why PdoProviderInterface and not PdoInterface ==* This also addresses a question raised by Alexander Makarov in the PR "Does it have to be bound to PDO?" ( https://github.com/php-fig/fig-standards/pull/1348#issuecomment-4040272736) The short answer is yes, and deliberately so. Early in my thinking I considered a PdoInterface that would mirror \PDO's full API. That approach touches PHP internals and RFC territory. It would also tightly couple the standard to PDO's own method signatures, which is a moving target. A single getConnection(): \PDO keeps the contract minimal and stable. \PDO is the only de facto standard for relational database access in PHP. This interface simply formalizes how you get access to it, not what it exposes. *== The real problem: library authors ==* With that in mind, the problem is better described as: a library should be able to benefit from another library's connection infrastructure without coupling itself to it. If I write a query builder or an event store library, my options today are: 1. Accept a raw \PDO -- simple, but I lose lazy-connect, auto-reconnect, and pooling 2. Depend on Doctrine DBAL -- I get those benefits, but I force that dependency on everyone using my library 3. Ship adapters for Doctrine, Laravel, Nette, etc. -- I get interoperability, but I maintain N adapters forever 4. Invent my own contract -- which is what I ended up doing *PdoProviderInterface* would be the missing fifth option: depend on a minimal contract, and let the consuming application plug in whichever DBAL manages the connection. == Concrete examples from my own work == In Backslash PHP (the event sourcing framework I maintain), I had to invent my own PdoInterface and a PdoProxy wrapper just to support lazy-connect. A standard interface would have solved that problem. You can see it here: https://backslashphp.github.io/docs/application-setup/defining-services/#configuring-the-pdo-connection I also maintain an internal enterprise application (Horizon) that has grown over the years to include Laravel, Doctrine DBAL for migrations, FluentPDO for query building, and other components depending on raw PDO. Each manages or consumes a connection independently. *PdoProviderInterface* would be the common thread letting all of them share the same managed connection. I cannot make this codebase public, but I suspect it is not an unusual situation for applications that have evolved organically. == Supporting research == To support this proposal with more than anecdotes, I put together a research repository that examines how 10 popular PHP database libraries handle connection creation, injection, and exposure: https://github.com/maximegosselin/pdo-provider-research It maps out the disparities between libraries and their readiness to adopt *PdoProviderInterface*. The patterns are consistent enough to suggest the problem is real, even if the solutions today are fragmented. ---------- I would be curious to hear from other library authors and from maintainers of applications that have grown beyond a single DBAL. This might be a problem that is common but invisible because everyone solves it in isolation. Regards, Maxime Gosselin Le jeu. 12 mars 2026, à 10 h 30, Larry Garfield <[email protected]> a écrit : > On Wed, Mar 11, 2026, at 1:06 PM, Maxime Gosselin wrote: > > Hi, > > > > I would like to propose a new PSR standardizing how PDO connections are > > provided between libraries. > > > > The problem has two sides. First, passing a \PDO instance directly > > surrenders control over the connection lifecycle: the caller loses the > > ability to control when and how the connection is opened, verified, or > > recreated. Second, there is no standardized contract for passing a > > connection between libraries. Widely-used libraries such as > > doctrine/dbal, illuminate/database, nette/database, and > > cakephp/database each wrap PDO in their own connection object, with no > > common interface. > > > > The proposed interface is intentionally minimal, modeled after PSR-20's > > ClockInterface: > > > > ========== > > namespace Psr\Pdo; > > > > interface PdoProviderInterface > > { > > public function getConnection(): \PDO; > > } > > ========== > > > > Draft PR: https://github.com/php-fig/fig-standards/pull/1348 > > > > Background: > https://maximegosselin.com/posts/proposing-a-psr-for-pdo-providers/ > > > > I intend to reach out to the Doctrine DBAL maintainers in the near > > future to gauge their interest. > > > > I am looking for a sponsor and working group members. > > > > Regards, > > Maxime Gosselin > > Let me see if I'm following. The original discussion on Reddit was about > a PdoInterface, which would be an Internals question and not something FIG > would be involved in. > > Now the proposal has shifted to effectively standardizing the "give me the > connection you're already wrapping" operation that many but not all DBALs > provide. The end goal is to allow an app to use Doctrine, Nette/Database, > and Aura SQL all in one application, all wrapping the same PDO connection > object. > > (This is fundamentally different than what PSR-20 does, where every > service is injected with a ClockInterface, and the clock is called > repeatedly to get a timestamp value object. That's not at all the same as > a way to extract one service dependency from another service.) > > I can somewhat see where that would be beneficial, as opening multiple PDO > connections to the DB in the same request causes all kinds of problems. > However, I am not sure how wide a use case that is. Essentially every > application I've seen has only a single DBAL, or it has a single DBAL plus > legacy code using a raw PDO object. In neither case would being able to > share the connection object between multiple DBALs be relevant. > > Right now, this feels more like a theoretical improvement rather than one > that addresses an extant problem in the ecosystem. Does anyone else have > different experience? > > --Larry Garfield > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/php-fig/ff37ac84-abf1-4f1d-875e-eb8b7d858c5e%40app.fastmail.com > . > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/php-fig/CAPhJx--TNnaJY_dYnFKtbf%2BtUu8d%3Dhj83bHLTv-JHX_ZB90ATg%40mail.gmail.com.
