Hi everyone, Just giving an update on the https://wiki.php.net/rfc/pdo_driver_specific_subclasses RFC as time is running out. The RFC text has been updated with the implemented subclasses stubs.
There are a few small things to note, and one larger thing: Marc Bennewitz wrote: > It would be great if driver specific constants would be added to the driver specific sub-classes without the driver name repeated in the const name. Okay, that will be done before it goes to vote. It probably has a downside of making there need to be a large duplication of tests, rather than being able to re-use the existing tests, but I guess it's probably worth doing. >> Create all DB sub-classes? > > yes please k. That has been done. Rowan Tommins wrote: > but as a minimum there should be an internal API for > registering a sub-class, without any modification to ext/pdo. There is now. The larger issue is whether to add an ini setting for SQLite extension loading or not. The sqlite3 PHP extension has an ini setting which limits extensions to be loaded from a particular directory, presumably as a safety precaution. The Sqlite3 extension uses the code: sqlite3_enable_load_extension(sqlite_handle, 1); which affects both the C api and loading extensions through SQL code. However, in the proposed PdoSqlite class this code: sqlite3_db_config(db, SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION, 1); is used to temporarily enable extension loading, which only enables it through the C api. As that means that SQLite extensions can only be loaded through C code (not through SQL), and if someone can upload and execute code to your server, your server is compromised anyway, having to edit ini files to enable extension loading, seems like a bad tradeoff. Thoughts? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
