On Tue, 16 Jun 2020 11:32:01 +0100 / Peter Bowyer <phpmailingli...@gmail.com> said :
> Hi list, > > 4 months ago there was a discussion about the future of SQLite3 and > PDO/SQLite extensions (https://externals.io/message/108256), > highlighting the effort required to maintain two codebases. Yes and I haven't had time to write a RFC or write any code on that yet, but hopefully I will have some time next year... > PDO is well established as providing a standardised access layer > across databases. SQLite requires extensions to be loaded to gain > feature parity with other databases (e.g. to load geospatial > functions) and since it is not a database server these have to be > loaded at runtime. PDO has three sqlite-prefixed functions > (https://www.php.net/manual/en/ref.pdo-sqlite.php) but not one to > load extensions. > > Is it a problem to add one? Yes adding driver-specific methods to PDO has been refused by PHP developers when I did a RFC on adding a couple methods for SQLite, even though there's already a bunch of other methods for other drivers like Postgre. What I was thinking was not exactly what Dan was proposing as I remember the driver-specific code to be very much linked to the PDO class and changing that would be a lot of work, so I was more thinking about adding a "getDriver()" method on PDO that would return a "PDO_SQLite" instance (or other drivers) and this class would have driver-specific methods. I dont exactly remember why the inheritance path suggested by Dan seemed way too complex as I haven't had time to work on this for a long time, but if it is actually possible it also seems like a good way to go :) I personally already use a wrapper-class that implements the same PDO methods but using the SQLite3 class underneath as it's the only one to provide access to advanced features like setting the authorizer callback, backup API and others. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
