> > That change was implemented in the SQLite3 extension without a RFC, so I'm > quite confused here. >
My literal reading of the contribution guide[1] is that new features should be preceded by an RFC, though there are certainly cases where this doesn't happen. I don't have a clear enough understanding of this community to say when RFCs can be skipped. I'm not sure who the authority would be. The release manager for the next minor rev? Anyone with commit privileges? I kinda feel like it's a weird thing to submit an RFC that would basically > ask the question "should pdo_sqlite only implement a subset of SQLite", > because well it is most likely that if you are using a DB driver with PDO > you most likely want to be able to access that DB features, no? > > Or are you saying that we should have a vote on whether the implementation > should follow what is already existing in PDO or should propose something > new instead? Because I frankly don't know what would be a better idea than > driver-specific methods and I don't know enough C/have enough time to do > anything else, so I won't submit any proposition that I won't be able to do > myself. > Only speaking for myself: I'd just want the RFC to act as a sanity check that the method you're adding has the right signature and it's being implemented consistently with similar methods. I don't like the design pattern either, but it's not like you're introducing it. It's better for PDO to be feature complete than to have a perfect architecture. A tool missing functionality will be less desirable to use. I'd be more concerned about the consequences of that state. Whoever wants to figure out the right way to support extension-specific methods would have to figure out how to deprecate the existing methods. Adding one wouldn't really change the scope of this problem, which isn't intractable in the greater scheme of things. Thanks, Adam --- [1] https://github.com/php/php-src/blob/master/CONTRIBUTING.md
