Re: Matching PDO_SQLite features with SQLite3 extension

PDO is already a mess, and adding method that appear/disappear dynamically whether you enable an extension or not... is a horror show. From my PoV, since we (doctrine) have to abstract away from it all the time, we'd rather have it as tidy and well-thought-out as possible, especially since there already is so much damage done. Couldn't care less about exposed/unexposed features if the endpoints are on the wrong object, or cause even more weirdness to work with. It is not helpful: it's just more tech debt dumped on millions of consumers. On 23 Aug 2017 4:39 AM, "BohwaZ/PHP" <php@bohwaz.net> wrote: > Yes, because once it lands in core, it sticks around for almost eternity. >> > > Yeah but is it necessary for something that is just missing, because the > pdo_sqlite implementation is incomplete, and is basically following what > already exists, without changing anything? > > That change was implemented in the SQLite3 extension without a RFC, so I'm > quite confused here. > > 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. > > Cheers. >