> > PDO already has support for large objects (LOBs)[1]. I don't know if >>> and how these are supported by the pdo_sqlite driver, but wouldn't it >>> make sense to use the existing API instead of introducing a new >>> method? >>> >>> [1] <http://www.php.net/manual/en/pdo.lobs.php> >>> >>> >> Very interesting indeed, didn't know about that feature, I was >> expecting the creation of a new method was the only way, as this was >> the way PGSQL was doing it. >> >> There's even a bug report about it: >> https://bugs.php.net/bug.php?id=57691 >> >> I will look into that next week and see if it can fit and replace my RFC >> then. >> > > > OK, I took some time to look into that feature and the fact is that it > doesn't work at all currently with SQLite, it is not returning a resource > handle but a string, and it is consuming a large amount of memory as it is > just dumping the LOB in memory. The code seems to be there to handle it > though so I don't know what's going on, if the person who implemented that > could come forward and tell me more about the implementation.
I believe that's how PDO::PARAM_LOB is intended to work (based on my reading of the docs and implementations for other drivers). It seems like more of a convenience than anything, though maybe someone had more ideas for how it should work across drivers and never got to follow through on it. The RFC is agreeable to me because it follows the existing ext/sqlite3 API and uses the existing pattern in pdo_sqlite for integrating driver-specific APIs. I'd love it if PDO had better BLOB/LOB types and if we had a better pattern for driver-specific APIs, but I'm comfortable lumping those goals under "future scope." Getting parity with ext/sqlite3 will make pdo_sqlite more usable, which will help grow its community, and the number of people who are able to contribute to these bigger projects. Deprecating the current set of driver-specific APIs in the future, if we have functional equivalents, isn't an impossible project. Thanks, Adam
