I am with Larry on this one, while I like it in theory - in practice this is not something I see an actual need for as a PSR.
On Thu, Mar 12, 2026 at 4:13 PM <[email protected]> wrote: > [email protected] > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/php-fig/topics> > [image: > Google Groups Logo] > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/php-fig/topics> > > - Proposal: PdoProviderInterface (PSR for providing PDO connections) > <#m_-3318906761327932280_group_thread_0> - 4 Updates > > Proposal: PdoProviderInterface (PSR for providing PDO connections) > <http://groups.google.com/group/php-fig/t/6ea932b0d830f64e?utm_source=digest&utm_medium=email> > Maxime Gosselin <[email protected]>: Mar 11 11:06AM -0700 > > 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 > Matteo Beccati <[email protected]>: Mar 12 09:49AM +0100 > > Hi Maxime, > > Il 11/03/2026 19:06, Maxime Gosselin ha scritto: > > > 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. > > Thanks for your proposal. I think that gauging the interest from DBAL > and a few other projects is key in order to find support and sponsors. > > I personally have a few doubts on the usefulness of such interface being > maintained by FIG, but let's hear what their feedback is. > > > > Cheers > -- > Matteo > Paul Dragoonis <[email protected]>: Mar 12 08:54AM > > > and a few other projects is key in order to find support and sponsors. > > > I personally have a few doubts on the usefulness of such interface being > > maintained by FIG, but let's hear what their feedback is. > > I'm sharing the same position at Matteo. > > My overall question is: > What is the impact of adding this PSR? and what's the current impact by not > having it? > > > > Larry Garfield <[email protected]>: Mar 12 09:29AM -0500 > > On Wed, Mar 11, 2026, at 1:06 PM, Maxime Gosselin wrote: > > > 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 > Back to top <#m_-3318906761327932280_digest_top> > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/php-fig/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to [email protected]. > -- 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/CACB5p2sdrTwNHSsPCQrCOYJos7GrRxMHFShFdWJFkzLuHS5NYA%40mail.gmail.com.
