Should we add the static connect method to every child class, since we can polyfill it there? How does this method behave when given a DSN for another driver and when it's called on a child class?

We could, but that feels a bit off to me. The whole idea of thePDO::connect static method is that it is able to detect the type of driver and thus subclass to use from the provided dsn, making it generic. Calling e.g.\Pdo\Mysqlite::connect(...) instead of justnew \Pdo\Mysqlite(...) makes little sense to me, and probably should not be something to actively encourage in any userland code?

About the connect method on child classes, I'd still add it, for completness of the polyfill

I probably will look into the last bits next week; if anyone is eager to finalize on theconnect method or think of additional tests to throw in here, feel free to add them.

Calling e.g.\Pdo\Mysqlite::connect(...) instead of justnew \Pdo\Mysqlite(...) makes little sense to me, and probably should not be something to actively encourage in any userland code?

But if you are on PHP 8.4, would you really call the constructor of those subclasses instead ofPDO::connect()? So either way, we're encouraging userland code that is different with the polyfill than with the real thing, mainly because we cannot polyfillPDO::connect(). 😕

But if you are on PHP 8.4, would you really call the constructor of those subclasses instead ofPDO::connect()? So either way, we're encouraging userland code that is different with the polyfill than with the real thing, mainly because we cannot polyfillPDO::connect(). 😕

To be fair, if one is currently only using something likenew PDO("sqlite:foo");, then migrating towardsnew Pdo\Sqlite("sqlite:foo"); does not seem like a weird strategy to me. In particular for projects were the driver class is already predetermined and you want to have the added benefit of stricter types for static analysis, one could prefer this overPDO::connect which will from a static point of view only ever returnPDO. However I do agree that the main usecase would still be to usedPDO::connect, which unfortunately is not something we can provide.

I think this should be complete now as is. Additional feature-like tests could be nice, but on the other hand are probably very hard to implement in practice without any real database and I think the current set should suffice to prove this should work in practice. In particular the migration towards 'polyfilled' constants should be very safe to do with this.

@nicolas-grekas with PHP 8.5 stable coming up next week, is there any chance of aiming to review and release this somewhere within that timeframe?

Can you please proceed with these CS changes on all classes?

Done!